skillify

Skillify

このセッションの再現可能なプロセスを、再利用可能な SKILL.md スキルファイルとして記録します。記録したいプロセスの最後に、任意で説明を付けて呼び出してください。

入力

• $description: (任意) スキルとして記録したいプロセスの説明。

ゴール

現在のセッションから再現可能なプロセスを記録し、後で再び呼び出せる、構造化された再利用可能な SKILL.md ファイルを作成します。

手順

1. セッションを分析する

質問をする前に、会話を分析して以下を特定します:

• どのような再現可能なプロセスが実行されたか
• 入力/パラメーターは何だったか
• 個別のステップ (順番どおり)
• 各ステップの成功成果物/基準 (例: 単なる「コードを書くこと」ではなく、「CI が完全に通過したオープンな PR」)
• ユーザーがどこで修正や方向づけを行ったか
• どのようなツールと権限が必要だったか
• どのようなエージェントが使用されたか
• ゴールと成功成果物は何だったか

成功基準: プロセス、そのステップ、入力、出力、成功基準について明確なメンタルモデルができていること。

2. ユーザーにヒアリングする

すべての質問には AskUserQuestion を使用します。プレーンテキストで質問しないでください。各ラウンドでは、ユーザーが満足するまで必要なだけ繰り返します。ユーザーには常に自由記述の「その他」オプションがあり、編集やフィードバックを入力できます -- 独自の「要調整」オプションを追加しないでください。実質的な選択肢のみを提示してください。

ラウンド 1: 高レベルな確認

• 分析に基づいてスキルの名前と説明を提案します。ユーザーに確認または名前変更を求めます。
• スキルの高レベルなゴールと具体的な成功基準を提案します。

ラウンド 2: より詳細な内容

• 特定した高レベルなステップを番号付きリストとして提示します。詳細は次のラウンドで掘り下げることをユーザーに伝えます。
• スキルに引数が必要だと思われる場合は、観察した内容に基づいて引数を提案します。誰かが何を提供する必要があるかを必ず理解してください。
• 不明確な場合は、このスキルをインライン (現在の会話内) で実行するか、フォーク (独自のコンテキストを持つサブエージェントとして) で実行するかを尋ねます。フォークは、プロセス途中でのユーザー入力が不要な自己完結型タスクに適しており、インラインは、ユーザーがプロセス途中で方向づけを行いたい場合に適しています。
• スキルをどこに保存するかを尋ねます。コンテキストに基づいてデフォルトを提案します。選択肢:
  • このリポジトリ (.claude/skills/<name>/SKILL.md) -- このプロジェクト固有のワークフロー向け
  • 個人用 (~/.claude/skills/<name>/SKILL.md) -- すべてのリポジトリで自分に付いてくる

ラウンド 3: 各ステップの分解

各主要なステップについて、明らかに明白でない場合は、以下を尋ねます:

• このステップは、後のステップが必要とする何を生成しますか? (データ、成果物、ID)
• このステップが成功し、次に進めることを証明するものは何ですか?
• 続行する前にユーザーに確認を求めるべきですか? (特にマージ、メッセージ送信、破壊的な操作など、不可逆的なアクションの場合)
• 独立して並行実行できるステップはありますか? (例: Slack への投稿と CI の監視を同時に行う)
• スキルはどのように実行されるべきですか? (例: コードレビューの実施には常に Task エージェントを使用する、または一連の並行ステップに対してエージェントチームを呼び出す)
• ハード制約やハードな選好は何ですか? 必ず行うべきこと、または行ってはならないことは何ですか?

ここでは AskUserQuestion を複数ラウンド行ってもよく、特に 3 つ以上のステップがある場合や確認質問が多い場合は、1 ステップにつき 1 ラウンド行います。

重要: 設計に活かすため、セッション中にユーザーがあなたを修正した箇所に特に注意を払ってください。

ラウンド 4: 最終的な質問

• このスキルをいつ呼び出すべきかを確認し、トリガーフレーズも提案/確認します。(例: 「ユーザーが PR をリリースブランチにチェリーピックしたいときに使用します。例: 'cherry-pick to release'、'CP this PR'、'hotfix'」)
• まだ不明確な場合は、その他の注意点や気をつけるべきことを尋ねます。

十分な情報が得られたらヒアリングを終了します。単純なプロセスに対して過度に質問しないでください!

成功基準: SKILL.md ファイルを書くために必要なすべての情報が揃い、ユーザーが設計を確認していること。

3. SKILL.md を作成する

ラウンド 2 でユーザーが選択した場所に、スキルのディレクトリとファイルを作成します。次の形式を使用します。

---
name: {{skill-name}}
description: {{one-line description}}
allowed-tools:
  {{list of tool permission patterns observed during session}}
when_to_use: {{detailed description of when Claude should automatically invoke this skill, including trigger phrases and example user messages}}
argument-hint: "{{hint showing argument placeholders}}"
arguments:
  {{list of argument names}}
context: {{inline or fork -- omit for inline}}
---

# {{Skill Title}}

Description of skill

## Inputs

- `$arg_name`: Description of this input

## Goal

Clearly stated goal for this workflow. Best if you have clearly defined artifacts or criteria for completion.

## Steps

### 1. Step Name

What to do in this step. Be specific and actionable. Include commands when appropriate.

**Success criteria**: ALWAYS include this! This shows that the step is done and we can move on. Can be a list.

各ステップの注釈（該当する場合に含めます）:

• 成功基準はすべてのステップで必須です。
• 実行: Direct（デフォルト）、Task agent（シンプルなサブエージェント）、Teammate（真の並列性とエージェント間通信を備えたエージェント）、または [human]（ユーザーが実行）。Direct 以外の場合にのみ指定が必要です。
• 成果物: このステップが生成し、後続のステップが必要とするデータ（例: PR 番号、コミット SHA）。後続のステップがそれに依存する場合にのみ含めます。
• ヒューマンチェックポイント: 続行する前に一時停止してユーザーに確認するタイミング。不可逆的な操作（マージ、メッセージ送信）、エラー判定（マージコンフリクト）、または出力レビューに含めます。
• ルール: ワークフローに対する厳格なルール。参照セッション中のユーザーの修正は、ここで特に役立ちます。

ステップ構造のヒント:

• 同時に実行できるステップはサブ番号を使用します: 3a、3b
• ユーザーが操作する必要があるステップは、タイトルに [human] を付けます
• シンプルなスキルはシンプルに保ちます -- 2 ステップのスキルでは、すべてのステップに注釈を付ける必要はありません

Frontmatter のルール:

• allowed-tools: 必要最小限の権限（Bash ではなく Bash(gh:*) のようなパターンを使用）
• context: 途中でユーザー入力が不要な自己完結型のスキルにのみ context: fork を設定します。
• when_to_use は重要です -- モデルがいつ自動呼び出しするかを指示します。「Use when...」で始め、トリガーフレーズを含めます。
• arguments と argument-hint: スキルがパラメータを取る場合にのみ含めます。本文では置換に $name を使用します。

成功基準: 完全な SKILL.md の内容が下書きされていること。

4. レビューと保存

ファイルを書き込む前に、完全な SKILL.md の内容をレスポンス内に yaml コードブロックとして出力し、ユーザーが適切なシンタックスハイライトでレビューできるようにします。次に、AskUserQuestion を使用して「この SKILL.md を保存してよさそうですか？」のような簡単な質問で確認を求めます。

書き込み後、ユーザーに以下を伝えます:

• スキルが保存された場所
• 呼び出し方: /{{skill-name}} [arguments]
• SKILL.md を直接編集して改善できること

成功基準: ファイルがディスクに書き込まれ、ユーザーにその使用方法が伝えられていること。