skill-creator

スキル作成ツール

組み込みのデフォルトよりも高品質なスキルを生成する、調査に基づいたスキル作成ツールです。あらゆる設計上の決定は、Transformer がコンテキストを処理する仕組みに基づいています。

---

専門用語ペイロード

プロンプトエンジニアリングとルーティング： 専門用語ペイロード、二重レジスターの説明、語彙ルーティング、分布上の収束、注意予算、分布の中心、適切な抽象度、検索アンカー

スキルアーキテクチャ： 段階的な開示、コンテキストウィンドウ管理、U 字型注意曲線、YAML フロントマター、トリガー領域、構造的な区切り、3 段階の読み込み（メタデータ／SKILL.md／references）

行動設計： アンチパターンの確認リスト、検出シグナル、反例、命令形の指示、条件分岐、評価基準

品質とテスト： 標準例、少数ショット学習、15 年の実務経験者テスト、コンサルタント調の表現（禁止）、過剰なプロンプト、直近性バイアス

---

アンチパターンの確認リスト

以下は、この作成ツールが生成するスキルにおけるアンチパターンです。納品前に、生成したすべての SKILL.md をこのリストと照合してください。

1. 用語における汎用的なコンサルタント調の表現

検出： 用語ペイロードに、「ベストプラクティス」、「活用する」、「相乗効果」、「堅牢なソリューション」、「スケーラブルなフレームワーク」、「全体的なアプローチ」などの語が含まれています。15 年の実務経験者テストを適用してください。上級分野専門家が同僚にこの語をそのまま使うでしょうか。そうでなければ不合格です。 解決： 曖昧に示している汎用語をすべて、正確な分野用語に置き換えてください。「エラー処理のベストプラクティス」は、「サーキットブレーカーパターン（Nygard）、指数バックオフ、デッドレターキュー」のようにします。

2. 過剰なプロンプト

検出： SKILL.md が 500 行を超えています。同じ概念を「強調」のために異なる表現で 2～3 回述べています。指示に、「検討してみるとよいでしょう」、「役立つかもしれません」などの曖昧な表現が含まれています。 解決： 各指示は命令形で一度だけ述べてください。曖昧な表現は削除します。詳細な参考情報は references/ に移動してください。まず最小限のバージョンでテストし、モデルが明らかに失敗する箇所に限って詳細を追加してください。

3. 肯定的な指示のみ

検出： 「～してはいけない」や「～を避ける」に関する指針がありません。アンチパターンの確認リストもありません。スキルには、すべきことだけが記され、すべきでないことが一切記されていません。 解決： パターン名、検出シグナル、解決手順を含む、分野固有のアンチパターンを 5～10 個追加してください。否定的な制約がないと、モデルは分布の中心（最も汎用的で平均的な出力）に引き寄せられます。

4. 単一レジスターの説明

検出： 説明に形式的な専門用語しか使われていないか、くだけた表現しか使われていません。次の点を確認してください。ユーザーが「[タスクのくだけた表現]を手伝って」と言ったとき、このスキルは起動するでしょうか。起動しないなら、くだけた表現が不足しています。 解決： 専門知識へのルーティングに使う専門用語と、確実な起動に使う自然言語のトリガーシナリオの両方を含むよう、説明を書き直してください。「ユーザーが[形式的な用語]を使わない場合でも」といった明示的な表現を追加してください。

5. エッジケースの詰め込み

検出： 具体的なエッジケースのルールが 15 個を超えています。パターンを示す代わりに、あらゆるシナリオを網羅する「X の場合は Y」の長いリストがあります。 解決： パターンを示す、バリエーションのある標準例を 3～5 個に絞ってください。難しいケースを 1 つ含めます。ルールを暗記させるのではなく、例からモデルに一般化させてください。Anthropic の公開されている推奨例は 3～5 個です。LangChain のベンチマークでは、効果において 3 個の例が 9 個とおおむね同等でした（効果は逓減しますが、厳密な上限ではありません）。

6. 段落形式のロジック

検出： 複数段階の複雑な動作が、散文の段落で説明されています。番号付きの手順も、IF/THEN 条件も、命令形の動詞もありません。 解決： 明示的な条件を含む、命令形の順序付き手順に書き換えてください。「まずアンチパターンがないか確認し、見つかった場合は対処したほうがよいでしょう」は、「1. 入力を確認してアンチパターンを検出する。検出した場合：検出・命名・説明・解決・予防の手順を適用する。検出しなかった場合：手順 2 に進む。」のようにします。

7. 例の不足

検出方法： 生成されたスキルに、入力と出力の例、または BAD/GOOD のペアが1つもありません。スキルが口頭での指示だけに全面的に依存しています。 解決方法： 多様な例を3～5個追加します。品質基準には BAD と GOOD のペア、ワークフローには入力と出力のペアを使います。最も代表的な例を最後に配置します（新近性バイアスにより、最も強い影響を与えます）。

8. 現行モデルへの過剰な規定

検出方法： 生成された SKILL.md に網羅的なルールが列挙されている、すべての指示に留保が付いている、または旧世代の能力が低いモデル向けに調整されたような内容になっている（語彙やアンチパターンのセクションは簡潔なのに、全体が密で列挙的になっている）。 解決方法： 目標、境界、検証基準を示し、適切な既定の判断はモデルに任せます。説明は強く促すものにします（トリガー設定は依然として弱点です）が、本文は簡潔に保ちます。既存のスキルを新世代のモデルに移行する場合は、指示を追加する前に、指示を削除することで出力が改善するかどうかをテストします。

9. 推論の逐語化を求める指示

検出方法： 行動に関する指示で、モデルに「思考の連鎖を示す」「推論プロセスを文字起こしする」「内部の思考を段階的に説明する」よう求めています。 解決方法： 結論と簡潔な理由を述べるよう求める指示に置き換えます（例：「段階を示し、その理由を1文で説明してください」）。適応的な思考によって内部で処理されるようになったため、手動での CoT の足場づくりは現在では推奨されません。Claude Fable 5 では、推論の逐語化を求める指示が推論抽出の拒否分類器を作動させ、リクエストが完全に失敗することがあります。

---

行動に関する指示

フェーズ 1：意図の把握

1. スキルで何を実行するのか、いつ起動するのか、期待される出力形式を特定します。
2. 対象ユーザーを特定します。このスキルを起動するのは誰で、通常どのように依頼するのでしょうか？
3. ユーザーの依頼が曖昧な場合：分野、起動シナリオ、期待される出力形式について、確認の質問を1～2個します。汎用的なスキルの作成に進んではいけません。

フェーズ 2：調査（条件付き）

4. なじみのない分野の場合：草案の作成前に、その分野を調査します。
   • 分野の用語、フレームワーク、名称の付いたパターンをウェブ検索します。
   • スキルがプロジェクト固有の場合は、コードベースを調査します。
   • 15年の実務経験者の基準を満たす専門用語を15～30個特定します。
   • 定着した名称のある分野のアンチパターンを5～10個特定します。

フェーズ 3：SKILL.md の草案を作成する

5. デュアルレジスターの説明文（約100語、強い表現、三人称、何をするかと、どんなときに使うかを記述）を含む YAML フロントマターを記述します。

   • 専門用語と、自然な言葉で表現したトリガーとなる状況の両方を含めます。
   • 明確な除外事項（「次の場合には使用しないでください」）を含めます。
   • トリガーを積極的に設定します。現在のモデルはトリガーが控えめになりがちです。同義語、エッジケース、隣接するシナリオも含めます。
   • プラットフォームの制限（Claude Code、2026）：説明文は最大1024文字です。説明文と when_to_use の合計は、約1%のコンテキストウィンドウを占めるスキル一覧の枠内で1,536文字に切り詰められます。使用頻度の低いスキルから除外されるため、余分な記述で補えるとは限りません。説明文そのものに加えてトリガーの範囲を広げるには、when_to_use を使います。
   • ほかに役立つフロントマター：disable-model-invocation、user-invocable、allowed-tools、model、effort、context: fork（フォークしたサブエージェントでスキルを実行）、paths（glob によるスコープ指定の有効化）。SKILL.md は Agent Skills オープン標準（agentskills.io）に準拠しています。カスタムスラッシュコマンドはスキルに統合されています。

6. 専門用語のペイロードを作成します（3〜5個のクラスターに分けた15〜30語）。

   • 行動指示より前に配置します。理由：語彙によって、実行開始前にルーティングのシグナルを与えられます。
   • 3〜8語からなるサブドメインごとのクラスターに整理します。
   • 名前付きフレームワークには、提唱者の帰属を含めます。「circuit breaker」だけではなく、「circuit breaker（Nygard）」とします。
   • すべての用語に15年の実務経験者テストを適用します。基準を満たさない用語は削除します。

7. アンチパターンの注意リストを作成します（名前付きパターンを5〜10個）。

   • 行動指示より前に配置します。理由：通常の実行に進む前に、モデルが問題の有無を確認するようになります。
   • 各パターンには、名前、提唱者、検出シグナル、解決手順を記載します。
   • 既存の名称がある場合は、それを使います。「詳細に時間をかけすぎる」ではなく、「Bikeshedding（Parkinson）」とします。

8. 行動指示を記述します（命令形、順序付き、条件分岐を含む）。

   • 「試してください」ではなく、「確認する」「分類する」「出力する」のような命令形の動詞を使います。
   • 各手順に番号を付けます。分岐ロジックには IF/THEN を使います。
   • 自明でない手順には理由を記載します。理由：モデルは原則をエッジケースにも一般化できますが、例外のない規則では文字どおり一致するケースしか扱えません。
   • 最初の手順をアンチパターンのスキャンにします。
   • 本文は簡潔に保ちます。Claude 4.5 以降／5 は簡潔な指示を確実に実行します。あらゆるケースを列挙し、すべての手順に過度な留保を付けるやり方は、古く性能の低いモデル向けに調整されたもので、現在のモデルでは出力品質を下げる可能性があります。スキルを移行する際は、指示を追加する前に、削除すると結果が改善するかをテストします。
   • モデルに内部推論の復唱や書き起こしを指示しないでください（「思考の連鎖を見せてください」「段階を追って考えを説明してください」など）。代わりに、結論と簡潔な理由を求めます。理由：Claude Fable 5 では、推論の復唱を求める指示によって、推論抽出の拒否判定器が作動することがあります。

9. 出力形式の仕様を作成します。

   • 必須フィールド、構造、テンプレートを定義します。
   • 散文より、YAML、表、番号付きリストなどの構造化形式を使います。

10. 多様な例を3〜5個作成します（BAD 対 GOOD、または入力から出力への例）。

    • 少なくとも1つの難しいケースを含む、異なるケースを扱います。
    • 最も代表的な例を最後に配置します。理由：新近性バイアスにより、最後の例が出力に最も強く影響します。

11. 「このスキルが答える質問」セクションを作成します（自然な言葉による質問を8〜15個）。

    • ファイルの末尾に配置します。理由：検索の手がかりは、コンテキスト末尾への注目が高まる U 字型カーブの効果を得られます。
    • カジュアルな表現や曖昧な表現も含め、ユーザーが実際に入力しそうな言い回しを正確に使います。
    • これらは、検索の手がかり、自己文書化、テストケースとして同時に機能します。

フェーズ 4：参照ファイル（条件付き）

12. スキルに大量の参照コンテンツ（パターンライブラリ、詳細な例、チェックリスト、評価基準）が必要な場合：

    • references/ ディレクトリにファイルを作成します。
    • 各参照ファイルは300行未満にします。
    • 各参照ファイルをいつ読むべきか、SKILL.md に明確な指示を記載します。

13. SKILL.md 全体を500行未満にします。500行を超える場合は、コンテンツを references/ に移動します。

フェーズ 5：ライブラリのメタデータ

14. YAML フロントマターに、ライブラリのメタデータ（名前、バージョン、ドメインタグ、互換性に関する注記）を含めます。

フェーズ 6：検証とパッケージ化

15. 生成した SKILL.md を上記のアンチパターン・ウォッチリストと照合します。違反があれば修正します。
16. サブエージェントを利用できる場合：実際のユーザーが入力するような、現実的なプロンプト（カジュアルで曖昧、専門用語を使わないもの）を3～5個使ってテストします。
17. スキルをパッケージ化します。構造を検証し、zip 形式に圧縮して、インストールには present_files を使用します。
18. library/skills/ に保存し、index.json を更新します。
19. 作成内容を usage-log.jsonl に記録します。

---

出力形式

主な出力は、完全なスキルディレクトリです。

skill-name/
  SKILL.md              # Core instructions (<500 lines)
  references/           # Optional: heavy reference content
    [topic].md          # Each file <300 lines

SKILL.md の内部構成（この順序で記載）：

1. YAML フロントマター（name、description、任意で when_to_use/allowed-tools/model/effort/context/paths）
2. 専門用語ペイロード
3. アンチパターン・ウォッチリスト
4. 動作指示
5. 出力形式
6. 例（BAD 対 GOOD）
7. このスキルが回答する質問

---

例

例 1：BAD 対 GOOD の説明

BAD：

description: "Helps with code review."

単一のレジスター。押しが弱い。専門用語がない。トリガーとなるシナリオがない。除外条件がない。このスキルが起動することはほとんどなく、起動しても一般的な出力しか生成されません。

GOOD：

description: |
  Performs structured code review using cyclomatic complexity analysis,
  connascence taxonomy, and conventional comments (Slaughter). Use when
  the user asks to review code, check a PR, look at their changes, or
  says "is this good?" about code -- even if they don't mention "review."
  Also triggers for diff review, merge request feedback, and pre-commit
  quality checks. Do NOT use for architecture decisions (use Decision
  Advisor) or writing new code (use Code Generator).

2つのレジスター。強く促す。専門用語から詳細な知識へ誘導します。カジュアルなトリガーにより確実に起動します。明示的な除外条件により誤起動を防ぎます。

例 2：BAD 対 GOOD の語彙ペイロード

BAD：

## Domain Vocabulary
good code, clean code, readable, maintainable, well-tested

どのブログ記事にもある一般的な用語です。入門的なコンテンツへ誘導します。15年の実務経験を持つ人の基準を満たしません。上級エンジニアが同僚に「良いコード」と言うことはありません。

GOOD：

## Domain Vocabulary
**Structural Analysis:** cyclomatic complexity (McCabe), cognitive
complexity (SonarSource), afferent/efferent coupling (Martin),
connascence (Page-Jones)

**Change Safety:** shotgun surgery (Fowler), feature envy, divergent
change, Liskov substitution violation

**Review Process:** conventional comments (Slaughter), ship/no-ship
framework, diff review vs design review, LGTM criteria

正確な用語をクラスターごとに整理しています。提唱者を明記したフレームワークを含みます。一般的な助言ではなく、コードレビューの専門知識へ誘導します。すべての用語が15年の実務経験を持つ人の基準を満たします。

---

パッケージ化に関する明示的な注記

このスキルは、提供にあたり Anthropic 独自の .skill パッケージ化の仕組み（validate、zip、present_files）を使用します。組み込みのスキル作成機能は呼び出しません。組み込みの方法に代えて、Forge の統合による、調査に裏付けられた原則を採用します。

• 語彙によるルーティング（正確な用語を使うことで、出力が一般的な学習データの中心から離れます。「埋め込みクラスターの活性化」はここで役立つ実用モデルですが、実証された仕組みではありません）
• U 字型の注意配分の最適化（語彙を前方に配置し、検索用の手掛かりを後方に配置します。現在の最先端モデルでは、旧来のベンチマークと比べてコンテキスト中盤の性能低下が大幅に小さくなっていますが、前後に配置するのが引き続き安全な既定の方法です）
• 否定的な制約による誘導（アンチパターンによって、一般的な出力の中心から外れるよう促します）
• 段階的な開示（3段階のコンテキスト読み込み。Claude Code はスキルの説明を1,536文字で切り詰め、auto-compaction 後は呼び出された各スキルにつき約5Kトークンのみ保持するため、重要な情報を前方に配置します）
• 少数例による優位性（多様な例を3～5個示すほうが、冗長な指示より効果的です。それ以上では効果が逓減します）

このスキル全体で使用する数値範囲（語彙用語15～30個、クラスター3～5個、アンチパターン5～10個、説明文約100語、トリガーとなる質問8～15個）は、網羅性を保ちつつ希薄化を避けるための Forge の設計基準であり、測定された閾値ではありません。SKILL.md を500行未満にする上限は、Anthropic のガイダンスで確認済みです。引用と適用範囲を含む簡潔な調査資料は ./references/skill-principles.md を、注釈付きのゴールドスタンダードの例は ./references/skill-template.md を参照してください。

このスキルが答える質問

• 「［ドメイン／タスク］向けのスキルを作成する」
• 「［X を実行する］スキルを構築する」
• 「［トリガー］が発生したときに、Claude が常に［動作］するようにしたい」
• 「再利用可能な［ドメイン］ヘルパーを作成する」
• 「優れたスキルを作成するにはどうすればよいですか？」
• 「このワークフローをスキルに変換する」
• 「［タスク］向けのスキルが必要です」
• 「カスタムの［ドメイン］アシスタントを作成する」
• 「［タスク］向けのプロンプトテンプレートを作成する」
• 「これをスキルとしてパッケージ化する」
• 「スキルを効果的にする要素は何ですか？」
• 「スキルが起動しません。修正するにはどうすればよいですか？」
• 「SKILL.md はどのように構成すればよいですか？」