同じ手順を書いても、機能するSkillと機能しないSkillに分かれます。差が出るのは完了条件、判断基準、やらないことの3点をどこまで具体的に書けているかです。

第1章で、良いSkillの条件として3つを挙げました。完了条件、判断基準、やらないことです。この章では、それぞれを実際にどう書けば機能するのかを、悪い例と良い例を対比しながら掘り下げます。

粒度の目安は「新人に渡す作業手順書」

SKILL.mdを書くとき、手順をどこまで細かく書けばいいか迷う人は多いはずです。目安は「その業務を初めて担当する新人に渡す作業手順書」だと考えてください。業務を熟知した人同士なら「いつも通りお願い」で通じますが、新人には通じません。何を確認し、どこで手を止め、何をもって終わりとするかを、暗黙の了解に頼らず書き出す必要があります。AIも同様で、会話の文脈だけでは埋まらない前提を、SKILL.mdの中に明示しておく必要があります。

完了条件は機械的に判定できる形で書く

完了条件が曖昧だと、AIはどこで作業を止めていいか分からず、中途半端な状態で終えるか、逆に必要以上に手を加え続けます。

悪い例良い例
良い感じに整える見出しは32文字以内、リンク切れゼロ
読みやすく直す1文60字以内、受動態ゼロ、見出し直下に結論を1文
ちゃんとテストする既存のテストが全件成功し、新規追加した関数に最低1件のテストがある

良い例に共通するのは、数値や有無で判定できることです。「文字数」「件数」「ゼロかどうか」のように、人によって解釈が割れない基準を選びます。

判断基準は分岐点ごとに用意する

手順書には書ききれない分岐が、実際の作業には必ず出てきます。判断基準は、その分岐点でAIが止まらないようにするための一文です。

## 判断基準
- 表記が旧字体と新字体で揺れている場合は新字体に統一する
- 出典が2つ以上見つかった場合は発行日が新しいほうを採用する
- 文字数が上限を超える場合は具体例を削り、結論は残す

判断基準を書かないSkillは、実行中にAIから「Aの場合とBの場合、どちらにしますか」という質問が飛んできます。1回や2回なら構いませんが、同じ種類の質問が繰り返されるなら、それはSkillに判断基準が足りていない合図です。

やらないことは事故を防ぐための一文

手順を足すよりも、やらないことを1行書くほうが事故を防げる場面があります。特に外部への影響を伴うSkillでは必須です。

## やらないこと
- 本文の主張や結論は変更しない
- 承認なしに公開・送信操作は行わない
- 既存のテストコードは削除しない

SKILL.mdの例

ここまでの3点を反映すると、SKILL.mdは次のような形になります。

---
name: article-review
description: 公開前の記事を文章規範に沿って点検する。「記事をレビューして」「公開前チェック」で使う
---

## 手順
1. 見出し構成が読者の検索意図に沿っているか確認する
2. 各段落の主張と根拠が対応しているか確認する
3. 文章規範チェックリストと照合する

## 完了条件
- 見出しは32文字以内
- リンク切れゼロ
- 1文60字以内が9割以上

## 判断基準
- 文章規範と媒体固有ルールが衝突する場合は媒体ルールを優先する
- 事実確認ができない記述は削除ではなく執筆者に確認を戻す

## やらないこと
- 本文の主張や結論は変更しない
- 承認なしに公開操作は行わない

書いたSkillのテスト方法

SKILL.mdは書いて終わりではなく、実際に呼び出して検証する工程が要ります。手順は単純です。

  1. Skillを実際に呼び出し、想定する作業を最後まで実行させる
  2. 途中でAIから質問が来たら、その質問に答える
  3. 答えた内容を判断基準としてSKILL.mdに追記する
  4. 再度呼び出し、同じ質問が出なくなるまで1〜3を繰り返す

この反復を数回行うと、質問が出なくなる地点に達します。そこが、そのSkillが実務で機能する最低ラインです。一度で完璧な判断基準を書き切ろうとするより、実際に動かして足りない部分を都度埋めるほうが早く仕上がります。

置き場所と呼び出しの仕組みは第2章で解説しています。