レッスン3: ハンズオン: 最初のスキルを書く

学習目標:

• スキルのディレクトリ構造を作る
• SKILL.md をゼロから丸ごと書き上げる
• 段階的開示（progressive disclosure）の原則を理解する
• 自分のスキルを初めて呼び出す

前提: << レッスン2 | 次: レッスン4 >>

今回作るもの

このレッスンでは、何もないところから実際に使えるスキルを作ります。テーマはタスク整理ツールです。

何をするものか:

• 入力: 雑然と積み上がったto-do（ばらけたテキスト、スクリーンショットから抜き出した文章、会議メモなど）
• 出力: 優先度と期日でグループ分けした、すっきりしたリスト

なぜこれを選ぶのか:

• シンプルで、邪魔になるような複雑なロジックがない
• 実用的で、今日から使い始められる
• スキルの構造の核となる部分を、ひととおり全部使う

ステップ1: ディレクトリとファイルを作る

ターミナルを開いて、次を実行します。

ここまでで、ディレクトリ構造はこうなっています:

~/.claude/skills/└── task-organizer/    └── SKILL.md

お好みのテキストエディタ（VS Code、Cursor、何でも構いません）で SKILL.md を開きます。

ステップ2: フロントマターを書く

まずはファイル冒頭のメタデータから始めます。¹

チェックリスト:

• ✓ name は小文字でハイフンつなぎになっている
• ✓ description は、何をするか（to-doを整理する）、何を受け取るか（雑然としたリスト）、いつ使うか（会議のアクションアイテム、プロジェクトのバックログ）をカバーしている

ステップ3: タイトルと導入を書く

frontmatterの後ろに、見出しを足します。

タイトルと導入をわざわざ書く理由:

• タイトルは人間のため。3か月後にこのファイルを開いても、一目で用途を思い出せます
• 導入はClaudeのため。description に収まりきらなかった細部を補います

ステップ4: 入力フォーマットを定義する

どんな入力を受け付けるかをClaudeに伝えます。²

このセクションが果たす役割:

• スキルが目にする可能性のある入力の形を、すべて列挙している
• 具体例をひとつ示すことで、実際の入力がどんな見た目になるのかを Claude に伝えている

ステップ5: 処理ステップを書く

ここが指示の心臓部で、具体的に書き込む必要があります。²

ここまで細かく書く理由:

Claude は人間ではないので、「言いたいことを察してくれる」わけではありません。「優先度を割り当てる」とだけ書いても、どんな基準で判断すればいいのか見当がつきません。「'urgent' を含む → Urgent」と書けば、推測の余地はもう残りません。³

ステップ6: 出力フォーマットを定義する

結果がどんな見た目になるべきかを Claude に伝えます。

例を示すことで得られるもの:

いったん Claude が例を目にすれば、レイアウト、記号、書式が確定します。絵文字をどこに置くのか、時刻はタスクの前なのか後なのか、といった迷いがなくなります。

ステップ7: エッジケースに対処する

変わったケースの扱い方を明示しておきます。

完成したファイル

これで、あなたの SKILL.md はこうなっているはずです。

ファイルを保存します。

ステップ8: 初めての呼び出し

Claude Codeを開いて、次のように入力します。

/task-organizer
四半期レポートを完成させるPR #234をレビュー、金曜までに明日ログインバグを修正ドキュメントを更新緊急: 顧客から報告された支払い問題

Claude は次のように返してくれるはずです。

### 🔴 緊急- ログインバグを修正 - 明日- 顧客から報告された支払い問題 - 期限なし
### 🟡 重要- PR #234をレビュー - 金曜
### ⚪ 通常- 四半期レポートを完成させる - 期限なし- ドキュメントを更新 - 期限なし

出力が思いどおりでなくても、慌てないでください。 次のレッスンはまるごとデバッグの話です。

段階的開示: なぜ細部を最初から全部書かないのか

このスキルが、他のタスクに依存するタスクや、別々の担当者に割り当てられたタスクについて何も語っていないことに、気づいたかもしれません。^{3 2}

これは意図的です。

段階的開示（progressive disclosure）: 一度に全部を押しつけるのではなく、Claude に今この瞬間に必要なものだけを渡す。³

最初のバージョンは、核となる仕事だけをして、それ以上はやりません。抽出し、分類し、並べ替える。数日使ってみて、タスクの担当者割り当てが本当に必要だと分かったら、そのとき足せばいいのです。

そこから得られるもの:

• 短いスキルファイル: 消費するコンテキストが少なく、読み込みが速い
• シンプルなロジック: 間違いようのある箇所が減る
• 核となる振る舞いが実際に動くことを、すぐに確認できる

まずバージョン1を動かし、それから反復する。良いスキルはどれも、このやり方で作られていきます。³

まとめ

• スキルを作る7つのステップ: ディレクトリ → フロントマター → タイトル → 入力 → ステップ → 出力 → エッジケース
• ステップは具体的に: 「タスクを分析する」ではなく「日付を表す語を探す: today、tomorrow…」
• 例が効く: 入力と出力が実際どんな見た目になるのかを Claude に見せる
• 段階的開示: バージョン1は核となる仕事だけをする — 細部を最初から全部書かない
• 呼び出し方: /skill-name に続けて入力を渡す

次のレッスンでは、スキルのテストとデバッグを扱います。「動く」から「正しく動く」へと進めていきましょう。

>> レッスン4: テストとデバッグ