skill-create

Codex 互換性に関する注意：

• Codex では $skill-name を使ってリポジトリのスキルを呼び出します。このミラー版では、従来の Claude の /skill-name 参照を書き換えています。
• タスクトラッカーの必須要件：ワークフローまたはスキルの手順を実行する前に、すべての手順のタスク追跡を作成／更新し、進捗に応じて同期してください。
• ユーザーへの質問を促す指示がある場合は、Codex でユーザーに直接質問してください。
• Claude 固有のモード切り替え指示がある場合は無視してください。
• 厳密な実行要件：ユーザーがスキルを明示的に呼び出した場合は、そのスキルのプロトコルを記載どおりに実行してください。
• サブエージェントの使用許可：ユーザーが呼び出したスキル、または AI が検出したスキルのプロトコルでサブエージェントが必要な場合、そのスキルの有効化により、そのタスクに必要な spawn_agent サブエージェントを使用する権限が与えられます。
• ユーザーが事前に逸脱を明示的に承認しない限り、プロトコルの手順を省略、並べ替え、統合しないでください。
• ワークフローのスキルでは、記載された各子スキルの手順を明示的に実行し、手順ごとの根拠を報告してください。
• 必須の手順やツールをこの環境で実行できない場合は、適応を試みる前に停止し、ユーザーに確認してください。

Codex でのプロジェクト参照資料の読み込み（フックなし）

Codex には、Claude のフックによるドキュメントの自動挿入機能がありません。 コーディング、計画、デバッグ、テスト、レビューを行う際は、この振り分けに従ってプロジェクトのドキュメントを明示的に開いてください。

必ず読むもの：

• docs/project-config.json（プロジェクト固有のパス、コマンド、モジュール、ワークフロー／テスト設定）
• docs/project-reference/docs-index-reference.md（docs/project-reference/* カタログ全体への案内）
• docs/project-reference/lessons.md（常時適用されるガードレールとアンチパターン）

状況に応じて読むもの：

• バックエンド／CQRS／API／ドメイン／エンティティの変更：backend-patterns-reference.md、domain-entities-reference.md、project-structure-reference.md
• フロントエンド／UI／スタイリング／デザインシステム：frontend-patterns-reference.md、scss-styling-guide.md、design-system/README.md
• 仕様／テストケースの計画または TC のマッピング：feature-docs-reference.md
• 統合テストの実装／レビュー：integration-test-reference.md
• E2E テストの実装／レビュー：e2e-test-reference.md
• コードレビュー／監査：code-review-rules.md に加え、変更ファイルに応じた上記のドメインドキュメント

すべてのドキュメントを無差別に読まないでください。まず docs-index-reference.md を確認し、その後、タスクに関連するファイルだけを開いてください。

クイックサマリー

目標： 適切な構造を持つ新しい Claude Code スキルを作成するか、カタログ全体の無効なスキルヘッダーをスキャンして修正します。

ワークフロー：

1. 確認 — ユーザーに直接質問し、目的、トリガーキーワード、必要なツールを把握します
2. 既存のものを確認 — 類似スキルを検索し、重複を避けます
3. ひな形を作成 — ディレクトリと、フロントマターおよびクイックサマリーを含む SKILL.md を作成します
4. SYNC ブロックを追加 — sync-inline-versions.md の関連プロトコルチェックリストを含めます
5. 検証 — フロントマターとヘッダーを検証します
6. 品質を高める — 新しい SKILL.md に対して $prompt-enhance を呼び出し、注意喚起の質を高めます

主なルール：

• すべての SKILL.md には、最初の 30 行以内に ## Quick Summary（Goal／Workflow／Key Rules）を必ず含めてください（注意喚起）。
• description は [Category] プレフィックスとトリガーキーワードを含む 1 行にしてください
• SKILL.md は 500 行未満にし、詳細には references/ を使用してください
• 共有プロトコルは `` ブロックを使って必ずインライン化し、ファイル参照は絶対に使用しないでください（注意喚起）
• 最終品質チェックとして、新規／更新したスキルに対して $prompt-enhance を必ず呼び出してください（注意喚起）

モード

モード	トリガー	アクション
作成	$ARGUMENTS が新しいスキルを記述している	以下のワークフローに従ってスキルを作成します
スキャンと修正	$ARGUMENTS にスキャン、修正、検証、無効に関する記述がある	すべてのスキルを検証します

SKILL.md スキーマのリファレンス

フロントマターのフィールド（すべて任意）

---
name: my-skill # Lowercase, hyphens. Max 64 chars. Default: directory name.
description: '[Category] What it does. Triggers on: keyword1, keyword2.' # MUST ATTENTION be single-line
argument-hint: '[issue-number]' # Autocomplete hint for arguments
disable-model-invocation: false # true = user-only (/name), Claude cannot auto-invoke
user-invocable: true # false = hidden from / menu, Claude-only auto-invoke
context: inline # inline (default) or fork (isolated subagent)
agent: general-purpose # Subagent type when context: fork
model: inherit-4-5 # Model override. Default: session model
version: 1.0.0 # Project convention (non-official)
---

呼び出し制御マトリクス

設定	ユーザーが呼び出す	Claude が呼び出す	説明
デフォルト	はい	はい	説明はコンテキスト内に表示され、呼び出し時に読み込まれます
disable-model-invocation: true	はい	いいえ	ユーザー専用です。呼び出されるまでコンテキスト内に表示されません
user-invocable: false	いいえ	はい	メニューには表示されません。Claude が自動的に呼び出します

変数の置換

変数	説明
$ARGUMENTS	スキルに渡されるすべての引数
$ARGUMENTS[N] / $N	0 始まりのインデックスで指定する引数
${CLAUDE_SESSION_ID}	現在のセッション ID
!`command`	スキルの実行前にシェルコマンドを実行します

主なルール

• description は 1 行にします（複数行の YAML はカタログの解析を妨げます）
• 自動有効化のため、説明にトリガーキーワードを含めます
• [Category] 接頭辞を使います（例：[Frontend]、[Planning]、[AI & Tools]）
• SKILL.md は 500 行未満にし、詳細には references/ を使います
• 説明はコンテキストウィンドウの 2%（約 16,000 文字）で読み込まれます
• 拡張思考モードを有効にするには、スキルの内容に「ultrathink」を含めます

モード 1：スキルを作成する

ワークフロー

1. 要件を明確にする — 要件が不明確な場合は、目的、自動呼び出しかユーザー呼び出しか、トリガーキーワード、必要なツールについて、ユーザーに直接質問します
2. 既存のものを確認する — 類似するスキルがないか .claude/skills/*/SKILL.md を Glob で検索します。重複を避けてください。
3. ディレクトリを作成する — .claude/skills/{skill-name}/SKILL.md
4. フロントマターを記述する — 上記の ## SKILL.md Schema Reference セクションのスキーマに従います
5. 手順を記述する — 簡潔で実行可能な内容にし、段階的な開示を取り入れます
6. SYNC ブロックを追加する — このスキルに適用される共有プロトコルを特定します。.claude/skills/shared/sync-inline-versions.md を読み、関連する `` ブロックをインラインでコピーします。一般的なプロトコル：understand-code-first、evidence-based-reasoning、output-quality-principles
7. 最後にリマインダーを追加する — 想起しやすくするため、末尾に :reminder SYNC ブロックを使って重要なルールを再掲します
8. 参照資料を追加する — 内容が 200 行を超える場合は、詳細なドキュメントを references/ ディレクトリに移します
9. スクリプトを追加する — 必要に応じて、実行可能な補助ツールを scripts/ に作成します
10. 検証する — フロントマターの検証を実行します（モード 2 の単一ファイルチェックを参照）
11. 強化する — 完成した SKILL.md に対して $prompt-enhance を呼び出し、AI の注意を引きつける品質を高めます

フロントマターのテンプレート

---
name: { kebab-case-name }
description: '[Category] What it does. Triggers on: keyword1, keyword2.'
---

スキルの注意構造（必ず従うこと）

[Frontmatter]
[SYNC protocol blocks — top attention zone]
[## Quick Summary — Goal/Workflow/Key Rules]
[Detailed instructions — middle zone]
[## Closing Reminders — bottom attention zone with :reminder SYNC blocks]

理由： AI の注意力は冒頭と末尾で最も強くなります（初頭効果と親近効果）。重要なルールは両方の位置に配置してください。研究に基づく原則については $prompt-enhance を参照してください。

新しいスキル向け SYNC タグプロトコル

1. .claude/skills/shared/sync-inline-versions.md を読みます。すべてのプロトコルチェックリストの正式な参照元です
2. スキルに必要なプロトコルを特定します（例：調査スキルには understand-code-first と evidence-based-reasoning が必要です）
3. チェックリストの内容を、スキルの冒頭にある `` 開閉タグの間にコピーします
4. 末尾の Closing Reminders 内に、1 行の :reminder 版を追加します
5. MUST ATTENTION READ shared/ ファイル参照は絶対に使わず、必ず内容をインラインで記述します

ルール

• SKILL.md はドキュメントではなく、指示です。タスクの実行方法を Claude に教えます。
• description は 1 行にします（複数行の YAML はカタログの解析を妨げます）
• 自動有効化のため、説明にトリガーキーワードを含める必要があります
• 説明には [Category] 接頭辞を使います（例：[Frontend]、[Planning]、[AI & Tools]）
• SKILL.md は 500 行未満にし、詳細には references/ を使います
• 段階的な開示：フロントマター → SKILL.md の概要 → 参照ファイル
• トークン効率：すべての行に存在意義を持たせます

モード 2：無効なスキルをスキャンして修正する

検証項目

チェック項目	ルール	重大度
Frontmatter が存在する	--- の区切りが必要	エラー
Description が 1 行である	description の値にリテラルな改行がないこと	エラー
Description が空でない	見つけやすくするため、description が必要	警告
名前の形式	小文字、ハイフン、最大 64 文字	エラー
不明な公式フィールドがない	公式スキーマにないフィールドを報告	情報
Description にカテゴリがある	[Category] で始まること	警告
ファイルサイズ	SKILL.md は 500 行未満であること	警告
Quick Summary がある	最初の 30 行以内に ## Quick Summary があること	警告
SYNC タグの対応	開始タグごとに対応する終了タグがあること	エラー

スキャンのワークフロー

1. 検出 — すべてのスキルを対象に .claude/skills/*/SKILL.md を Glob する
2. 解析 — 各ファイルの最初の 20 行を読み、frontmatter を抽出する
3. 検証 — 上記の各ルールをチェックする
4. 報告 — 重大度別（エラー > 警告 > 情報）に問題を一覧表示する
5. 修正 — ユーザーが確認した場合、エラーレベルの問題を自動修正する

検証スクリプト

node .claude/skills/skill-create/scripts/validate-skills.cjs          # Report only
node .claude/skills/skill-create/scripts/validate-skills.cjs --fix    # Report + auto-fix

要件

$ARGUMENTS

---

[IMPORTANT] すべての作業を小さなタスクに分割するタスク追跡を、作業開始前に必ず使用してください。

批判的思考の姿勢 — 批判的思考と順序立てた思考を適用してください。すべての主張には追跡可能な根拠が必要であり、確信度が 80% を超える場合にのみ行動してください。 ハルシネーション対策： 推測を事実として提示しないでください。すべての主張に出典を示し、不確実な点は率直に認め、出力に誤りがないか自己確認し、独立して相互参照し、自分の確信度にも懐疑的でいてください。根拠のない確信は、あらゆるハルシネーションの根本原因です。

共有プロトコルの重複に関するポリシー — スキル内にインラインで記述されたプロトコル内容（`` で囲まれたもの）は、意図的な重複です。抽出、重複排除、ファイル参照への置き換えはしないでください。プロトコルをファイル読み込みの間接参照の背後に置くと、AI の遵守度が大幅に低下します。更新するには、まず .claude/skills/shared/sync-inline-versions.md を編集し、次に SYNC:protocol-name を grep して、すべての出現箇所を更新してください。

出力品質 — 品質を損なわずにトークンを効率よく使ってください。

1. 一覧や件数は出さないでください。AI は grep | wc -l を実行できます。件数はすぐに古くなります
2. ディレクトリツリーは出さないでください。AI は glob／ls を実行できます。パスの規則は 1 行で示してください
3. 目次は不要です。AI は順に読みます。目次はトークンの無駄です
4. ルールを繰り返す例は不要です。自明でない場合に限り、例を 1 つだけ示してください
5. 理由ではなく、回答から始めてください。冗長な言葉や前置きは省いてください
6. 報告では、簡潔さのために文法を犠牲にしてください
7. 未解決の質問があれば、最後に記載してください AI のミス防止 — あらゆるタスクで避けるべき失敗パターン：

削除する前に、後続の参照を確認してください。 コンポーネントを削除すると、ドキュメントやコードの古さが連鎖的に広がります。削除する前に、参照しているすべてのファイルを洗い出してください。 AI 生成コンテンツを実際のコードと照合してください。 AI は API、クラス名、メソッドのシグネチャを幻覚することがあります。ドキュメントに記載したり参照したりする前に、必ず grep で存在を確認してください。 編集後は依存関係を最後までたどってください。 定義を変更しても、そこから派生する後続の変数や利用箇所を見落とすことがあります。必ず依存関係をすべてたどってください。 正しさを検証するときは、すべてのコードパスをたどってください。 コードが存在することを確認しても、実行されることを確認したことにはなりません。正常系だけでなく、早期終了、エラー分岐、条件によるスキップも必ずたどってください。 デバッグ時は、修正する前に「どちらの責任か」を確認してください。 呼び出し元（誤ったデータ）に問題があるのか、呼び出し先（誤った処理）に問題があるのかをたどってください。責任のあるレイヤーで修正し、症状が現れる箇所だけを修正しないでください。 既存の値は意図的なものだと考え、変更前に理由を確認してください。 定数、上限、フラグ、パターンを変更する前に、コメントを読み、git blame を確認し、周辺のコードを調べてください。 最初の出力だけでなく、影響を受ける出力をすべて検証してください。 複数のスタックに影響する変更では、すべての出力を検証する必要があります。チェックが1つ成功しても、すべてが成功したことにはなりません。 全体を優先するデバッグ — 目の前の箇所だけに注目する罠を避けてください。 あらゆる障害を調査するときは、まず前提条件をすべて列挙してください（設定、環境変数、DB 名、エンドポイント、DI 登録、データの前提条件）。その後、コードレイヤーの仮説を立てる前に、それぞれを証拠と照らして検証してください。 変更は最小限に — 差分テストを適用してください。 バグ修正では、変更したすべての行がそのバグに直接関係している必要があります。隣接するコードのスタイルを整えたり、改善したりしないでください。機能強化タスクでは、改善を実装し、明示的に伝えてください。 コーディング前に曖昧さを明らかにし、黙って選択しないでください。 依頼に複数の解釈がある場合は、それぞれの所要時間の見積もりとともに提示し、確認してください。全レコード対象、ファイルベース、またはより複雑な方法を決めつけないでください。

重要・必ず注意 重複に関するポリシーに従ってください。インラインのプロトコルは意図的なものです。ファイル参照に切り出さないでください。

重要・必ず注意 出力品質の原則に従ってください。トークンを効率よく使い、回答を先に述べ、余計な文言を加えないでください。

必ず注意 批判的思考を適用してください。すべての主張には追跡可能な証拠が必要です。確信度が80％を超える場合にのみ実行してください。幻覚を避け、推測を事実として提示しないでください。

必ず注意 AI のミス防止を適用してください。全体を優先するデバッグ、責任のあるレイヤーでの修正、コーディング前の曖昧さの明示、コンテキスト圧縮後のファイル再読を徹底してください。

最後に確認すること

重要・必ず注意 作業を始める前に、タスク追跡を使って作業を小さな todo タスクに分割してください。 重要・必ず注意 `` ブロックを使って共有プロトコルをインラインで記述してください。MUST ATTENTION READ shared/ ファイル参照は絶対に使わないでください。 重要・必ず注意 新規または更新したスキルには、品質を最終確認するための注意付けとして最後に $prompt-enhance を呼び出してください。 重要・必ず注意 すべての SKILL.md の最初の30行以内に ## Quick Summary を含めてください。 重要・必ず注意 すべてのスキルの末尾に :reminder SYNC ブロックを含む「最後に確認すること」セクションを追加してください。 重要・必ず注意 公式のフロントマター項目については、SKILL.md Schema Reference（上記にインラインで記載）に従ってください。

[TASK-PLANNING] 作業に着手する前に、タスクの範囲を分析し、タスク追跡を使って作業とサブタスクを体系的に小さな todo タスクへ分割してください。

Hookless Prompt Protocol Mirror (Auto-Synced)

ソース：.claude/hooks/lib/prompt-injections.cjs + .claude/.ck.json

[WORKFLOW-EXECUTION-PROTOCOL] [BLOCKING] ワークフロー実行プロトコル — 必須・重要・厳守。いかなる理由があっても省略しないでください。

汎用的な移植性の境界： 再利用可能なスキルとプロトコルのテキストはプロジェクトに依存しないものとします。プロジェクト固有の規約は、docs/project-config.json と docs/project-reference/ から確認してください。shared/sdd-artifact-contract.md の共通 AI-SDD を適用します。docs/project-config.json と docs/project-reference/docs-index-reference.md を読み、そこに記載されているプロジェクト参照ドキュメントを開いてください。この共通コンテキストとローカルドキュメントを利用できる場合は、サポートされている任意の AI ツールで実行できます。

1. 検出： プロンプトをワークフローカタログと照合します
2. 分析： 最適なワークフローを見つけ、カスタムのステップ構成のほうが適しているかどうかも評価します
3. 確認（必須形式）： ユーザーが明示的にワークフロー／スキルを呼び出し、かつローカルプロトコルで明示的な呼び出しを確認とみなす場合を除き、次の構成でユーザーに直接質問します
   • 質問："どのワークフローを有効にしますか？"
   • 選択肢 1："[最適なワークフロー] を有効にする（推奨）"
   • 選択肢 2："カスタムワークフローを有効にする：[step1 → step2 → ...]"（1 行で理由を記載）
4. 有効化（確認後）： 標準ワークフローの場合は $workflow-start <workflowId> を呼び出し、カスタムステップの場合は手動で順に実行します
5. タスクを作成： ワークフローのすべてのステップについてタスク追跡を行います
6. 実行： 各ステップを順番に実行します [CRITICAL-THINKING-MINDSET] 批判的思考と段階的思考を適用します。すべての主張には追跡可能な根拠が必要であり、確信度が 80% を超える場合にのみ行動します。 ハルシネーション防止の原則： 推測を事実として提示しないでください。すべての主張に出典を示し、不確実な点は率直に認め、出力に誤りがないか自己確認し、独立した情報源と照合し、自分の確信を疑ってください。根拠のない確信こそが、あらゆるハルシネーションの根本原因です。 AI の注意力に関する原則（初頭効果・新近効果）： 長いプロンプト／プロトコルでは、指示の順守が長いコンテキストウィンドウでも保たれるよう、最も重要な 3 つのルールを冒頭と末尾の両方に配置します。 目標主導の実行： まず成功基準を定義し、検証が完了するまで繰り返し、観察可能なチェックに合格した場合にのみ終了します。 テストで意図を検証： テストでは、現在の挙動をなぞるだけでなく、ビジネスルール／不変条件を保護し、保護対象の意図が損なわれた場合に失敗するようにします。

[LESSON-LEARNED-REMINDER] [BLOCKING] タスク計画と継続的改善 — 必須。省略しないでください。

作業を始める前に、作業を小さなタスクに分割し、タスク追跡を行います。最後のタスクとして「AI のミスと教訓を分析する」を追加します。

教訓の抽出 — 症状への対処ではなく、根本原因のみ：

1. 症状ではなく、失敗モード（推論／前提の誤り）を特定します。「誤った列挙値を使った」ではなく、「ソースを読まずに API が存在すると仮定した」とします。
2. 一般性を検証します。この失敗モードは 3 つ以上のコンテキスト／コードベースに当てはまりますか？ 当てはまらない場合は、抽象度を 1 段階上げます。
3. 普遍的なルールとして記述します。プロジェクト固有の名前／パス／クラスを除き、どのコードベースでも役立つ内容にします。
4. 統合します。同じ失敗モードを共有する複数のミスは、1 つの教訓にまとめます。
5. 再発判定：「この注意書きがなければ、今後のセッションで再発するか？」いいえの場合は $learn を省略します。
6. 自動修正判定：「$code-review／$code-simplifier／$security／$lint で検出できるか？」はいの場合は、代わりにレビュー用スキルを改善します。
7. 両方の判定を通過した場合： $learn を実行するようユーザーに依頼します。 [TASK-PLANNING] [MANDATORY] ワークフローまたはスキルのステップを実行する前に、予定されているすべてのステップのタスク追跡を作成／更新し、各ステップの開始時と完了時に内容を同期してください。