Skill 作成

属人化している業務のやり方を聞き取り、そのまま配布できる Skill に変換する。

前提

良い Skill は、次の3つが書かれている。1つでも欠けると精度が落ちる。

1. 手順 — 何を、どの順番でやるか
2. 出力フォーマット — 完成物がどういう形をしているか
3. 守るべきルール — やってはいけないこと、判断に迷ったときの原則

このうち3番目が最も価値が高く、最も書かれにくい。ベテランが無意識に守っている判断基準がここに入る。

手順

1. 聞き取り

次の6つを質問する。答えが返ってくるまで作成に進まない。

質問5は言い換えを重ねて深掘りする。「新人がやりがちなミス」「レビューで毎回指摘すること」「これを間違えると事故になること」。ここで出てくる内容が Skill の質を決める。

2. 骨子の確認

聞き取った内容を次の形に整理し、作成前にユーザーに確認する。

対象業務:
入力:
出力:
手順: 1. ... 2. ... 3. ...
ルール: - ... - ...

認識が違っていれば、この段階で直す。SKILL.md を書いてから直すより速い。

3. SKILL.md の生成

templates/SKILL.md.template を雛形として使い、次の構成で書く。

• frontmatter（name / description / when_to_use）
• 入力として受け取るもの
• 手順（番号つき。1手順1動作）
• 出力フォーマット（コードブロックで実物の形を示す）
• 守るべきルール（箇条書き。太字で結論、続けて理由）
• 自社用にカスタマイズする（次に手を入れる箇所）

description には、その業務を頼むときに人が実際に使う言葉を入れる。「議事録作成支援機能」ではなく「議事録にして、会議メモをまとめて」。ここがAIの呼び出し判定に直結する。

4. テスト

実際の業務データを1件流して、出力を見る。

• 期待した形式で出たか
• ルールが守られているか
• 手順の途中で止まったり、勝手に省略していないか

うまくいかない場合は、失敗した箇所に対応する記述を SKILL.md に足す。プロンプトを長くするのではなく、具体例を1つ足す ほうが効く。

5. 配布

.claude/skills/<skill-name>/ に置いて Git にコミットする。これで同じリポジトリを使うメンバー全員が同じ Skill を使える。

出力するファイル構成

<skill-name>/
├── SKILL.md              必須。手順・フォーマット・ルール
├── references/           任意。長い基準・マスタ・チェックリスト
│   └── <name>.md
├── templates/            任意。出力の雛形ファイル
└── scripts/              任意。決まりきった処理のスクリプト

SKILL.md が長くなってきたら（目安 500行）、詳細を references/ に切り出し、SKILL.md からは参照だけを書く。参照先は必要になったときだけ読み込まれるため、常時の負荷が下がる。

守るべきルール

• 聞き取りを飛ばさない。 業務内容を推測して書いた Skill は現場で使われない。
• 1 Skill 1業務にする。 「営業支援Skill」のような大きな括りにしない。呼び出し判定が曖昧になり、精度が落ちる。
• 手順は1項目1動作にする。 「確認して修正する」は2つに分ける。
• ルールには理由を書く。 理由のないルールは、状況が変わったときに判断を誤る。
• 出力フォーマットは実物で示す。 説明文ではなくコードブロックで実際の形を書く。
• 固有名詞と数値を具体的に書く。 「社内フォーマット」ではなく、実際の項目名を列挙する。
• 機密情報を Skill に埋め込まない。 顧客名・単価・個人情報は Skill に書かず、実行時に渡す設計にする。公開リポジトリに置く可能性を常に前提にする。

つまずいたときの対処