prioritize

Codex 互換性に関する注意事項：

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

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

Codex では、実行時にプロジェクトドキュメントを注入する代わりに、静的なプロジェクト参照の読み込みを使用します。 コーディング、計画、デバッグ、テスト、レビューを行う際は、このルーティングに従ってプロジェクトのドキュメントを明示的に開いてください。

必ず読むもの：

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

コンテキストがない、または古い場合のルート： docs/project-config.json、ドキュメントインデックス、lessons.md、CLAUDE.md、AGENTS.md、またはタスクに必要な参照ドキュメントがないか古い場合は、通常のプロジェクト固有の作業に入る前に、$project-init または限定的なセットアップルート（$project-config、$docs-init、$scan-all、$scan --target=<key>、$claude-md-init）を自動実行してください。Codex ミラーまたは AGENTS.md がないか古い場合は、ユーザーに $sync-codex の実行を依頼してください。自動実行してはいけません。

状況に応じたドキュメント：

• プロジェクト構造、アーキテクチャ、技術スタック、デプロイ、セットアップ（バックエンド、フロントエンド、インフラのいずれの層でも）：project-structure-reference.md
• バックエンド／CQRS／API／ドメイン／エンティティの変更：backend-patterns-reference.md、domain-entities-reference.md
• フロントエンド／UI／スタイリング／デザインシステム：frontend-patterns-reference.md、scss-styling-guide.md、design-system/README.md
• 仕様書の作成、docs/specs/ のパス指定、または TC 形式：feature-spec-reference.md、spec-system-reference.md、spec-principles.md
• 動作や公開契約の変更、または仕様書・テスト・コードの同期：上記の仕様書ドキュメントとあわせて workflow-spec-test-code-cycle-reference.md
• 派生した仕様書インデックス／ERD／再実装ガイド：spec-system-reference.md および docs/specs/ 内の元となる Feature Specs
• 統合テストの実装／レビュー：integration-test-reference.md
• E2E テストの実装／レビュー：e2e-test-reference.md
• コードレビュー／監査作業：変更されたファイルに応じたドメインドキュメントとあわせて code-review-rules.md

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

[BLOCKING] スキルのステップは宣言された順序で実行してください。ユーザーが明示的に承認しない限り、ステップを省略、並べ替え、または統合してはいけません。 [BLOCKING] 各ステップまたはサブスキルの呼び出し前にタスク追跡を更新し、ステップの開始時に in_progress、終了時に completed を設定してください。 [BLOCKING] 完了またはスキップしたすべてのステップには、簡潔な根拠または明示的なスキップ理由を記載してください。 [BLOCKING] Task ツールが利用できない場合は、同じステータス遷移を反映した、同等のステップごとの計画トラッカーを作成し、維持してください。

クイックサマリー

目標： RICE、MoSCoW、またはValue-Effortフレームワークを使用して、3件以上のバックログ項目に根拠のある順位を付けます。チームが最も価値の高い項目から着手できるようにし、すべての順位をスコアと技術に依存しない根拠（価値／工数／リスク／影響）で裏付けます。

概要： 目的 — 3件以上のバックログ項目に順位を付け、チームが最も価値の高い項目から着手できるようにします。すべての順位には、スコアと技術に依存しない根拠を添えます。主な手順とタスクは次のとおりです。

• ステップ1～2：収集と選択 — まず3件以上の項目を必須とします（3件未満の場合は直接話し合い、フレームワークを決して無理に適用しません）。判断ツリーに基づいてフレームワークを選びます。定量データがある場合はRICE、ステークホルダーとのmust／should／couldの合意が必要な場合はMoSCoW、手早く判断する場合はValue-Effort 2x2を選びます。迷った場合はRICEをデフォルトにします。
• ステップ3：スコア付け — フレームワークの正確な計算式を適用します（RICE＝Reach×Impact×Confidence ÷ Effort、固定のImpact／Confidenceスケール、ストーリーポイントによるEffort）。独自のスコアを決して作りません。
• ステップ4～5：順位付けと出力 — 降順（RICE）、バンド別（MoSCoW）、または象限別（V-E）に順位を付け、スコアと「最優先で実施／次に計画／延期」の推奨を含む優先順位付きテーブルを出力します。
• ステップ6：反映（PBIファイルがある場合は必須） — 各PBIのfrontmatterに順位（1～999、昇順）と優先度ラベルを書き戻します。pbi-mockup／feature-presentationはそこから優先度を読み取ります。
• 横断事項 — 技術に依存しないこと（M1）： すべての順位を、価値／工数／リスク／ビジネスへの影響に基づいて説明し、名前を挙げた技術スタック／フレームワーク／パターンに基づく説明は決してしません。同点判定ゲート： ほぼ同点（RICEの上位2項目の差が15％以内、MoSCoWで同じバンド内の重複、または明示されたステークホルダー間の意見の不一致）がある場合は、$llm-councilを提示してユーザーに直接確認します。それ以外の場合は、確認を促さずに終了します。

ワークフロー：

1. 項目を収集する — ファイルから読み取るか、インラインリストを解析します（最低3項目）
2. フレームワークを選択する — RICE（定量的）、MoSCoW（ステークホルダーとの合意）、Value-Effort（迅速な判断）
3. 各項目にスコアを付ける — フレームワークの基準を適用してスコアを計算します
4. 順位付けして報告する — 根拠と推奨を添えた優先順位付きテーブルを出力します
5. 優先度を反映する — PBIファイルがある場合：各PBIのfrontmatterにrankとpriorityラベルを書き戻すことが必須です
6. 同点判定ゲート — ほぼ同点の場合は、ユーザーに直接確認します（$llm-councilを使うか、現在の結果を受け入れるか）。それ以外の場合は、確認を促さずに終了します

主なルール：

• 項目は最低3件必要です。3件未満の場合は直接話し合います
• 迷った場合はRICEをデフォルトにします。不明確な場合はユーザーに確認します
• 順位付け後にPBIファイルの優先度フィールドを更新することもできます
• 技術に依存しない根拠（M1）： .claude/skills/shared/sdd-artifact-contract.mdの「AI-SDD Mandates (M1-M7)」で、ブロッキングとなる基準を確認してください。すべての順位は価値、工数、リスク、ビジネスへの影響に基づいて説明し、実装技術に基づく説明はしないでください。根拠の文章はdocs/project-reference/spec-principles.md §3に従い、技術に依存しないものとします。フレームワーク／製品／言語／デザインパターンの名前は含めません。工数についてはストーリーポイントや相対的な複雑さに触れても構いませんが、特定の技術スタックの名前は挙げません。

懐疑的な姿勢を保ち、批判的思考と順序立てた思考を適用してください。すべての主張には追跡可能な根拠と確信度（パーセンテージ）が必要です（アイデアの確信度は80％を超える必要があります）。

バックログの優先順位付け

データに基づくフレームワークを使ってバックログ項目を並べ替え、スコアと根拠を添えた順位付きリストを作成します。

使用する場面

• スプリント計画で、バックログを順序付ける必要がある場合（順位付け対象は3件以上）
• ステークホルダーが、根拠を添えた優先順位を必要とする場合
• 客観的な基準に基づいて機能ロードマップを並べる場合
• 競合する機能や取り組みを比較する場合

使用しない場面

• 項目が3件未満の場合（直接話し合います）
• PBIの作成やストーリーの記述（product-ownerまたはstoryを使用します）
• 製品戦略全般（product-ownerを使用します）
• プロジェクトの進捗管理（project-managerを使用します）

前提条件

• バックログ項目（PBI、機能、ユーザーストーリー）が3件以上あること
• 項目がファイルとして存在する場合：team-artifacts/pbis/またはユーザー指定のパスから読み取ります
• 項目がインラインで提供される場合：提供された説明を使用します

ワークフロー

1. 優先順位を付ける項目を収集します

   • ファイルパスが指定されている場合 -> ファイルから項目を読み取ります
   • インラインリストの場合 -> ユーザーメッセージから項目を解析します
   • 項目が3つ未満の場合 -> 追加の項目をユーザーに尋ねるか、直接話し合うことを提案します

2. 決定木を使ってフレームワークを選択します

   定量データ（リーチ、指標）がある場合 -> RICE
   ステークホルダーの合意が必要な場合（Must／Should／Could） -> MoSCoW
   迅速な判断が必要な場合（2つの軸のみ） -> Value-Effort 2x2
   ユーザーがフレームワークを指定した場合 -> そのフレームワークを使用
   判断できない場合 -> ユーザーに尋ね、デフォルトではRICEを使用
   

3. 選択したフレームワークを使って各項目をスコアリングします

   RICE：

   スコア = (リーチ x インパクト x 信頼度) / 工数
   
   リーチ：      四半期あたりの影響を受けるユーザー数（数値）
   インパクト：  0.25（最小） | 0.5（低） | 1（中） | 2（高） | 3（非常に高）
   信頼度：      0.5（低） | 0.8（中） | 1.0（高）
   工数：        ストーリーポイント（1、2、3、5、8、13、21）
   

   MoSCoW：

   Must Have：   リリースに不可欠で、交渉の余地がない
   Should Have： 重要だが必須ではなく、回避策がある
   Could Have：  望ましい項目で、キャパシティに余裕があれば含める
   Won't Have：  今回の対象範囲外
   

   Value-Effort 2x2：

   高い価値 + 低い工数  = クイックウィン    （最初に実施）
   高い価値 + 高い工数  = 戦略的項目        （慎重に計画）
   低い価値  + 低い工数 = 補完項目          （時間があれば実施）
   低い価値  + 高い工数 = 時間の浪費        （回避）
   

4. スコア（RICEは降順、MoSCoWはカテゴリ別、V-Eは象限別）に基づいて項目を順位付けします

5. スコアと根拠を添えて、優先順位付きのリストを出力します

6. PBIファイルが存在する場合 -> 優先順位を必ず反映します。各PBIのフロントマターに、算出した優先順位（数値のrank（1～999、昇順）とpriorityラベル（例：Must Have / Should Have / Could Have / Won't Have、またはフレームワークのカテゴリ）の両方）を書き戻します。PBIファイルが存在する場合、これは任意ではありません。優先順位のないPBIは未完成であり、後続の利用者（pbi-mockupのヘッダーバッジ、feature-presentationのScope & backlogスライド）はPBIのフロントマターから優先順位を読み取ります。独立したバックログファイルだけでなく、順位付けしたすべてのPBIを更新してください。

出力形式

## Prioritized Backlog

**Framework:** [RICE | MoSCoW | Value-Effort]
**Date:** [YYMMDD]
**Items scored:** [count]

### Rankings

| Rank | Item      | Score | Rationale                                           |
| ---- | --------- | ----- | --------------------------------------------------- |
| 1    | Feature A | 45.0  | High reach (5000), high impact (3), high confidence |
| 2    | Feature B | 12.0  | Medium reach (2000), medium impact, low effort      |
| 3    | Feature C | 2.5   | Low reach, minimal impact, high effort              |

### Recommendations

- **Do first:** [top items]
- **Plan next:** [medium items]
- **Defer:** [low items with reasoning]

例

例1：5つの機能のRICEスコアリング

入力：「優先順位を付けてください：SSOログイン、ダークモード、PDFへのエクスポート、メール通知、一括インポート」

出力：

順位	機能	リーチ	インパクト	信頼度	工数	RICE
1	メール通知	5000	2	0.8	1	8000
2	SSOログイン	2000	3	0.8	3	1600
3	一括インポート	500	2	1.0	1	1000
4	PDFへのエクスポート	1000	1	0.8	2	400
5	ダークモード	3000	0.5	0.5	2	375

例2：MoSCoWによる分類

入力：「Q1リリース向けに分類してください：決済ゲートウェイ、管理ダッシュボードの再設計、APIのレート制限、ユーザーアバター、監査ログ」

出力：

• Must Have： 決済ゲートウェイ（収益に不可欠）、APIのレート制限（セキュリティ）
• Should Have： 監査ログ（コンプライアンス上必要。手動エクスポートで回避可能）
• Could Have： 管理ダッシュボードの再設計（効率は向上するが、現状のものでも機能する）
• Won't Have： ユーザーアバター（あると便利だが、Q2に延期）

オプションのエスカレーション：同点の場合の $llm-council

ゲートの評価： 優先順位付けされたバックログの作成後（## Workflow の手順の出力に従います）、ランキングの出力を確認します。

• 上位2件の RICE スコアの差が15％以内 → ゲートが発動します
• MoSCoW の明確な同点（同じ Must／Should／Could の分類で、範囲に実質的な重複がある項目が2件以上）→ ゲートが発動します
• 複数のステークホルダー間の意見の相違が入力で示されている → ゲートが発動します
• 上記のいずれにも該当しない → ゲートは発動しません。プロンプトを表示せずにスキルを終了します

必ず確認してください — ゲートが発動した場合、ユーザーに直接確認し、次の選択肢を提示する必要があります（architecture-design の ## Next Steps にある「必ず確認してください」ブロックと同じ前置きの形式です）。

• 「$llm-council にエスカレーションする（推奨）」 — 同点または意見の相違が検出されました。11のサブエージェントによる評議会を実行します（アドバイザー5名＋レビュアー5名＋議長）。評議会の「反対意見」と「外部視点」のレンズは、複数のPBIのランキングで同点になった場合に適しています。より低コストな代替案として、$why-review、$plan-validate があります（同点の範囲が狭く、通常のリスクであればこちらを使用してください）。
• 「スキップ — 現在のランキングを採用する」 — 同点を認識したうえで、現在のランキングで進めます。

ゲートが発動しない場合は、優先順位付けの決定をそのまま採用し、確認を求めないでください。

関連スキル

スキル	代わりに使用する場面
product-owner	プロダクト管理の全ワークフロー
story	PBIをユーザーストーリーに分割する場合
refine	アイデアをPBIに具体化する場合
project-manager	スプリント／プロジェクトの状況と追跡

---

プロンプト強化の締めくくりの注意事項

• 重要・必ず注意 このスキルで宣言されているステップの順序に従ってください。ユーザーから明示的な承認を得ずに、ステップを省略、並べ替え、統合してはなりません。
• 重要・必ず注意 各ステップ／サブスキルの呼び出しについて、実行前に in_progress に設定し、実行後に completed に設定してください。
• 重要・必ず注意 省略した各ステップには明確な理由を記載してください。完了した各ステップには簡潔な根拠を記載してください。
• 重要・必ず注意 Task ツールを利用できない場合は、ステータスを同期した同等のステップごとの計画トラッカーを維持してください。

プロジェクトプロトコルのオーバーレイ — このスキルを実行する前に、このスキルに適用される PROJECT オーバーレイのルールを解決してください。プロジェクトのスキルプロトコル索引（デフォルトでは docs/project-reference/skill-protocols-reference.md。docs/project-config.json の referenceDocs エントリでパスを上書きできます）の Target 列と、このスキルの名前を照合し、最も具体的に一致する階層のみを適用します（完全一致 > glob > *）。この優先順位はオーバーレイ同士にのみ適用され、このスキルとの優先順位を定めるものではありません。一致した本文のみを <protocols-dir>/<Name>.md として解決して読み取ってください。行の Body リンクは表示テキストであり、読み取り先ではありません。一致した本文が存在しない、または不正な形式の場合は、その旨を報告してスキップしてください。索引の Description から再構成してはなりません。索引がない場合、または一致するものがない場合は、オーバーレイなしで続行し、何も報告しません。契約の全文は .claude/skills/project-skill-protocol/references/registry.md にあります。

オーバーレイは追加のみです。このスキル独自のプロトコルにルールを追加するものであり、既存のルールを置き換えたり、上書き、無効化、再解釈したりしてはなりません。すべてのオーバーレイを取り除いた場合、このスキルは文書化された動作と完全に同じでなければなりません。オーバーレイは補足であり、権限を引き上げるものではありません。ワークフローのゲート、Git の規律、レビューのゲート、ユーザー確認のゲートを決して免除できません。オーバーレイとスキルの間に実際の矛盾がある場合、または同じ具体性の複数のオーバーレイが直接矛盾する場合は、両方をユーザーに提示してください。黙って解決してはなりません。

必ず注意 実行前に、このスキルのプロジェクトプロトコルのオーバーレイを解決してください。最も具体的に一致する階層のみを適用します（完全一致 > glob > *。これはオーバーレイ同士の優先順位であり、このスキルとの優先順位ではありません）。一致した本文のみを <protocols-dir>/<Name>.md から読み取ってください。本文が存在しない、または不正な形式の場合は報告し、再構成してはなりません。オーバーレイは追加のみであり、このスキル独自のルールを置き換えることはできません。また、オーバーレイは補足であり、権限を引き上げるものではありません。同じ具体性のオーバーレイが矛盾する場合は、ユーザーに提示してください。

締めくくりの確認事項

• 重要・必ず注意 目標： RICE／MoSCoW／Value-Effort を用いて、バックログ項目を3件以上、根拠を示せる順序でランク付けします。各順位にはスコアと、技術に依存しない根拠（価値／労力／リスク／影響）を付け、チームが最も価値の高い項目から取り組めるようにします。

適用中のプロトコル（このスキルに含まれる SYNC／共有ブロックの簡潔な要約）：

• 批判的思考： すべての主張について、必ず file:line の証拠を追跡してください。行動するには確信度が80％を超えている必要があります。推測を事実として示してはなりません。
• AI の誤り防止： 生成した内容を証拠に照らして検証し、下流の参照を追跡し、影響を受けるすべての出力を検証してください。コンテキストを失った後は読み直し、曖昧さがあれば明示してください。
• 重要・必ず注意 ランキング前に3件以上を求めてください。3件未満の場合は直接検討し、フレームワークを無理に適用しないでください。理由：1〜2件のランキングは、判断材料を増やさず、形式的な手順を増やすだけです。
• 重要・必ず注意 意思決定ツリーに従ってフレームワークを選択してください。定量データには RICE、ステークホルダー間で Must／Should／Could の優先順位を合わせるには MoSCoW、迅速に判断するには Value-Effort 2x2 を使います。迷った場合は RICE をデフォルトとし、曖昧な場合はユーザーに確認してください。理由：意思決定の種類に合ったフレームワークを選ぶことが、ランキングの説明可能性を高めます。
• 重要・必ず注意 優先順位付けした表（スコア＋根拠）と、先に実施／次に計画／延期の推奨事項を出力してください。生のスコアだけで終わらせないでください。理由：実際に役立つ出力は、ランキング表とアクションの判断であり、数値の列だけではありません。
• 重要・必ず注意 M1 に従い、すべての根拠をテクノロジーに依存しない内容にしてください。価値／工数／リスク／ビジネスへの影響で正当化し、具体的なスタック／フレームワーク／製品／言語／デザインパターンを根拠にしないでください。工数にはストーリーポイントと相対的な複雑さのみを記載できます。理由：spec-principles §3 の BLOCKING により、テクノロジー名を含む根拠は、優先順位の判断に実装の詳細を持ち込むことになります。
• 重要・必ず注意 正確なフレームワークの計算式でスコアを付けてください（RICE = Reach×Impact×Confidence ÷ Effort。Impact／Confidence は固定スケール、Effort はストーリーポイント）。その後、RICE は降順、MoSCoW は区分別、V-E は象限別に並べてください。独自のスコアを作らないでください。理由：根拠のあるランキングには、再現可能な数値が必要です。
• 重要・必ず注意 ほぼ同点の場合（RICE の上位2件の差が15％以内、MoSCoW で同一区分の項目が重複、またはステークホルダー間の意見の相違が指摘されている場合）は、ゲートが発動します。ユーザーに直接確認し、$llm-council によるエスカレーションか、ランキングの受け入れかを提示してください。ゲートが発動しない場合は、プロンプトを出さずに終了してください。理由：同点の決着はユーザーが判断するものですが、明確な勝者がいる場合は作業を中断する必要はありません。
• 重要・必ず注意 作業を始める前に、タスク追跡を使って作業を小さな todo タスクに分割してください。エビデンスが得られたら直ちに、1つを in_progress、次に completed としてください。
• 重要・必ず注意 新しい構造を作成する前に、コードベース／成果物から類似パターンを3件以上検索してください。近くにある例をコピーする前に、パターンの適合性（同じ制約／スコープかどうか）を評価してください。理由：最も近い例が、前提条件まで一致するとは限りません。
• 重要・必ず注意 すべての主張に file:line のエビデンスを引用してください。確信度が80％を超える場合にのみ対応し、60％未満の場合は推奨しないでください。推測を事実として提示しないでください。
• 重要・必ず注意 PBI ファイルが存在する場合、ランキング後に、各 PBI のフロントマターへランキングを反映することが必須です（数値の rank 1〜999 と priority ラベル）。任意ではありません。優先順位フィールドを変更する前に、下流の利用箇所を grep してください。理由：下流の利用箇所（pbi-mockup のヘッダー、feature-presentation のスコープとバックログのスライド）は、PBI のフロントマターから優先順位を読み込みます。古い優先順位参照や参照の欠落は、気付かれないまま連鎖的な問題を引き起こします。
• 重要・必ず注意 作業品質を確認するための最終レビュー todo タスクを追加してください。

合理化を避けるためのルール：

かわし方	反論
「項目は2つだけなので、順位を付ければよい」	3項目未満であれば、直接話し合います。フレームワークを使っても形式的な手順が増えるだけで、判断材料は増えません。
「根拠にフレームワークを引用します」	M1 に従い、技術に依存しない形で判断します。名前の挙がった技術スタックではなく、価値・労力・リスクのみを根拠としてください。
「スコアは十分近いので、こちらで選びます」	ほぼ同点ならゲートが発動します。黙って決めず、必ずユーザーに直接 $llm-council について尋ねてください。
「RICE が適切に思えるので、計算式は省きます」	固定の尺度を使い、正確な計算式を適用してください。根拠を示せる順位付けには数値が必要です。
「バックログファイルに順位があるので、PBI に書く必要はありません」	PBI ファイルが存在する場合、各 PBI のフロントマターへの優先度の書き戻しは必須です。モックアップとプレゼンテーションは、バックログではなく PBI から優先度を読み取ります。
「パターンはすでに把握しています」	file:line の証拠を示してください。証拠がなければ、検索してください。

必ず注意すること　批判的思考と段階的思考を適用してください。すべての主張には、適切な追跡可能な証拠が必要です（リポジトリ／コードに関する主張には file:line、調査、製品、コンテンツ、ドキュメントに関する主張にはソース URL または資料内のセクション）。確信度が80%を超える場合に行動し、60%未満の場合は推奨しないでください。ハルシネーション防止：推測を事実として提示せず、不確実さを率直に認め、独立して相互参照し、自分の確信度を疑ってください。

必ず注意すること　AI の誤りを防止してください。生成した内容を証拠と照合し、削除または名前変更の前に下流の参照を追跡し、影響を受けるすべての出力を検証し、コンテキストを失った後はファイルを読み直し、行動する前に曖昧さを明らかにしてください。

[TASK-PLANNING] 行動を開始する前に、タスクの範囲を分析し、タスク追跡を使って小さな ToDo タスクとサブタスクに体系的に分割してください。

[IMPORTANT] タスクの規模を分析し、開始前に多くの小さな ToDo タスクへ体系的に分割してください。これは非常に重要です。

[IMPORTANT] タスク追跡を使って、ファイルの読み取りごとのタスクも含め、作業を開始する前にすべての作業を小さなタスクに分割してください。これにより、長いファイルの作業中にコンテキストを失うのを防げます。簡単なタスクの場合、AI は必ず、これを省略してよいかユーザーに尋ねてください。

批判的思考の姿勢 — 批判的思考と段階的思考を適用してください。すべての主張には追跡可能な証拠が必要であり、行動するには確信度が80%を超えている必要があります。 ハルシネーション防止： 推測を事実として決して提示せず、すべての主張に出典を示し、不確実さを率直に認め、出力の誤りを自ら確認し、独立して相互参照し、自分の確信度を疑ってください。証拠のない確信こそ、あらゆるハルシネーションの根本原因です。 AI のミス防止 — あらゆるタスクで避けるべき失敗パターン：

コンテキストが変わったらファイルを読み直してください。 コンテキストの圧縮、作業の再開、長時間にわたる作業によって、記憶が古くなることがあります。作業に取りかかる前に、現在のファイルを確認してください。 生成した内容をソースの根拠と照合してください。 AI は API、名前、主張、文書の事実を幻覚することがあります。文書に記載したり参照したりする前に、該当するソースを確認してください。 削除や名前変更の前に、下流の参照を確認してください。 成果物を削除すると、ドキュメント、生成されたミラー、設定、呼び出し元が古くなることがあります。まず参照箇所を特定してください。 編集後は影響範囲を最後までたどってください。 定義を変更しても、派生した出力や利用者への影響を見落とすことがあります。完了と判断する前に、影響を受ける連鎖をたどってください。 最初の出力だけでなく、影響を受けるすべての出力を確認してください。 1 つのチェックが成功しても、すべてのチェックが成功したとは限りません。変更によって影響を受ける可能性のあるすべての出力先を検証してください。 既存の値は意図的に設定されたものと考え、変更したり欠陥として指摘したりする前に、その理由を確認してください。 定数、上限、フラグ、しきい値、表現、パターンを変更または報告する前に、周辺のコンテキストと履歴、呼び出し元の処理順序、同じ規約を使う 2 つ以上の類似した呼び出し箇所を確認してください。理由を示さず「何をするか」だけを記したドキュメントは、根拠が不足しているのであって、ガードが欠けている証拠ではありません。 曖昧さがあれば、行動する前に明らかにしてください。黙って決めつけないでください。 妥当な解釈が複数ある場合は、明示的に質問するか、リスクを添えて前提を明示してください。 中間状態ではなく、システムが所有する結果を検証してください。 非同期処理を検証する際は、最終的な業務状態を確認してください。共有インフラストラクチャに記録された配信や再試行の管理情報は、同時に実行されるどのプロセスからも書き換えられるため、決して検証対象にしないでください。そのようなチェックは単独実行では成功しても、別の処理が同じインフラストラクチャを共有した途端に不安定になります。 共有ガイダンスは、対象となる役割に関係する内容にしてください。 普遍的なガイダンスは、それを受け取るすべてのスキルやエージェントに役立つものである必要があります。コード固有の要件は、コード固有のプロトコルにのみ記載してください。

Hookless Prompt Protocol Mirror（自動同期）

ソース：.claude/.ck.json + .claude/skills/shared/sync-inline-versions.md（:full ブロック）+ .claude/scripts/lib/hookless-prompt-protocol.cjs

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

汎用的な移植性の境界： 再利用可能なスキルとプロトコルのテキストはプロジェクトに依存しないものとし、プロジェクト固有の規約は docs/project-config.json と docs/project-reference/ から確認します。共有 AI-SDD は shared/sdd-artifact-contract.md に従って適用します。docs/project-config.json と docs/project-reference/docs-index-reference.md を読み、そこに記載されているプロジェクトリファレンスドキュメントを開いてください。仕様、テストケース、動作変更、公開コントラクト、または docs/specs/ に関する作業では、ドキュメントインデックスに記載されたローカルの仕様ドキュメント（feature-spec-reference.md、spec-system-reference.md、spec-principles.md、および仕様・テスト・コードの同期が必要な場合は workflow-spec-test-code-cycle-reference.md）を経由してください。いずれかのファイル、または必須のリファレンスドキュメントが見つからないか古くなっている場合は、通常のプロジェクト固有の作業に進む前に $project-init（または $project-config、$docs-init、$scan-all、$scan --target=<key> などの限定的な下位ルート）を自動実行してください。この共有コンテキストとローカルドキュメントが利用可能であれば、サポート対象の任意の AI ツールで実行できます。

1. 検出： プロンプトが明示的なスラッシュ形式のスキル／ワークフローコマンドで始まる場合は、それを直接実行します。それ以外の場合は、プロンプトをワークフローカタログとスキルリストに照らし合わせます。
2. 分析： 最適な方法を選択します。直接実行、スキルの呼び出し、標準ワークフローの開始、またはカスタムのステップ構成です。
3. 自動選択： 最適な方法を自分で選択します。直接実行、スキル、標準ワークフロー、カスタムワークフローのどれにするか、ユーザーに選択を求めてはいけません。
4. 開始： 選択したワークフローでは $start-workflow <workflowId> を呼び出します。選択したスキルではそのスキルを呼び出します。カスタムワークフローではカスタムステップを順に実行します。直接実行ではタスクに進みます。
5. タスクの作成： 選択した経路に複数のステップがある場合、実行前にすべてのワークフロー／スキル／カスタムステップについてタスクを追跡します。
6. 並列化： タスクリストの実行前に、各タスクに PAR（入力が独立しており、書き込み対象が他のすべての PAR タスクと重複しない）または SEQ（ブロックする依存関係を明記）を付け、PAR タスクをウェーブにグループ化し、ウェーブ計画を宣言して、各ウェーブのサブエージェントを1つのメッセージで起動します。各ウェーブでは全員の完了を待ち、サブエージェント自身の定義でさらなる並列化が認められている場合を除き、ファンアウトは1階層までとします。独立したタスクを逐次処理するのは不備です。共有の書き込み対象、出力を利用するタスク、単純な単一ファイルの作業、スキルやワークフローで順序が明示されている作業、ユーザー承認が必要な段階は並列化しないでください。
7. 実行： コンテキスト指示にある Workflow Step Advancement & Parallel Phases のルールに従って進めます。ステップの進行はモデル主導です。サブエージェントの完了はインライン呼び出しと同様にステップを進めます。並列フェーズのグループは全員の完了を待つバリアです（すべてのメンバーが完了した後にのみ進み、決して逐次化しません）。

共有 AI-SDD プロトコルマーカー

ソース：.claude/skills/shared/sync-inline-versions.md

SYNC:ai-sdd-artifact-contract

AI-SDD 成果物契約 — 共有する仕様駆動開発のルールは、移植可能な状態に保ち、ソース側で管理します。

1. 再利用可能な AI-SDD の原則は .claude に置き、リポジトリ固有のパス、コマンド、担当者、製品、形式はプロジェクト設定または参照ドキュメントに記載します。
2. サイクルを維持します：spec -> plan -> tasks -> implement -> verify -> update spec/docs。
3. すべての要件または不変条件を、判断、タスク、TC／テスト、ソースの根拠、ドキュメント／仕様の更新まで追跡します。
4. コードから仕様への抽出は、正規の仕様オーナーが承認するまでは参照専用として扱います。
5. 同期されたコンテキストがあれば、サポート対象の AI ツールで計画、実装、レビュー、検証を行えます。複数のツールを使うかどうかは任意です。
6. まず .claude のソースを更新してから、生成されたミラーを同期します。.agents、.codex、AGENTS.md を手動で編集しないでください。— 理由：ミラーは生成された成果物であり、次回の同期時に手動編集内容が上書きされます
7. docs/project-config.json、ルートの指示ファイル、または必須のプロジェクト参照ドキュメントが欠落しているか古い場合は、通常のプロジェクト固有の作業を行う前に、$project-init または適切な下位レベルの手順を自動実行します。

有効な参照先： アクティブなスキルルート内の shared/sdd-artifact-contract.md。

---

SYNC:ai-sdd-artifact-contract:reminder

• 必須 shared/sdd-artifact-contract.md を適用し、再利用可能な AI-SDD は .claude に、ローカルルールはプロジェクトのドキュメントに保持します。
• 必須 コードから仕様への抽出は、正規の承認を得るまで参照専用です。サポート対象の AI ツールであれば、同期されたコンテキストを使って実行できます。
• 必須 生成されたミラーを同期する前に .claude のソースを更新します。.agents、.codex、AGENTS.md を手動で編集しないでください。
• 必須 プロジェクト設定、ルートの指示ファイル、または必須の参照ドキュメントが欠落しているか古い場合は、プロジェクト固有の作業を $project-init または適切なセットアップ手順に自動的に振り分けます。 [TASK-PLANNING] [必須] ワークフローまたはスキルの手順を実行する前に、計画したすべての手順についてタスク追跡を作成／更新し、各手順の開始時と完了時に同期してください。

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

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

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

1. 症状ではなく、失敗モード（推論や前提の誤り）を特定します。「間違った enum 値を使った」ではなく、「ソースを読まずに API が存在すると仮定した」とします。
2. 一般性を確認します。この失敗モードは 3 つ以上の状況／コードベースに当てはまりますか？当てはまらない場合は、もう一段階抽象化します。
3. 普遍的なルールとして記述します。プロジェクト固有の名前、パス、クラスを取り除きます。どのコードベースでも役立つ内容にします。
4. 統合します。同じ失敗モードに起因する複数のミスは、1 つの教訓にまとめます。
5. 再発ゲート：「このリマインダーがなければ、今後のセッションで再発するか？」いいえ → $learn は省略します。
6. 自動修正ゲート：「$code-review／$code-simplifier／$security-review／$lint で検出できるか？」はい → 代わりにレビュー用スキルを改善します。
7. 両方のゲートを通過した場合は、ユーザーに $learn の実行を依頼します。 [CRITICAL-THINKING-MINDSET] 批判的思考と段階的思考を適用します。あらゆる主張に追跡可能な証拠を求め、行動する際は確信度を 80% 超とします。 ハルシネーション防止の原則： 推測を事実として提示しないでください。すべての主張に出典を示し、不確実性を率直に認め、出力に誤りがないか自己確認し、独立した情報源と照合し、自分の確信を疑ってください。証拠のない確信が、あらゆるハルシネーションの根本原因です。 AI の注意力の原則（初頭効果・新近効果）： 長いプロンプト／プロトコルでは、最も重要なルールを上部と下部の両方に 3 つずつ配置し、長いコンテキストでも指示への準拠を維持します。 目標主導の実行： まず成功基準を定め、検証できるまで繰り返し、観察可能なチェックに合格した場合にのみ終了します。 テストは意図を検証します： テストは現在の動作をなぞるだけでなく、ビジネスルールや不変条件を保護し、保護対象の意図が崩れたときに失敗する必要があります。

よくある AI のミスを防ぐ（システムの教訓）

• コンテキスト圧縮後はファイルを再読込してください。 編集するには、同じコンテキスト内で事前に Read している必要があります。圧縮によって読込状態は消去されます。編集前に再読込してください。
• 一括置換後は古い用語を grep してください。 AI は検索・置換の完全性を過信します。一括編集後はリポジトリ全体を grep し、ドキュメント／設定／カタログに参照漏れがないか確認してください。
• 削除前に下流の参照を確認してください。 削除の影響は、ドキュメントやコードの陳腐化へ連鎖します。削除前に参照元ファイルを洗い出してください。
• 記憶を失った後、新しく作成する前に既存の状態を確認してください。 圧縮によってこれまでの作業の記憶が消去されます。作業を再開するときは現在の状態を確認し、決してむやみに重複作成しないでください。
• AI 生成コンテンツは実際のコードと照合してください。 AI は API、クラス名、メソッドシグネチャを幻覚することがあります。ドキュメントへの記載や参照の前に、grep して実在を確認してください。
• 編集後は依存関係を最後までたどってください。 定義を変更しても、その下流の利用箇所を見落とすことがあります。依存関係をすべてたどってください。
• 名前を変更するときは、利用側の全ファイル形式を grep してください。 ファイル形式によっては、参照先が見つからなくてもエラーなしで無視されます。コード、テンプレート、設定、生成ファイルを検索してください。
• 正しさを検証するときは、すべてのコードパスをたどってください。 コードが存在することと、実行されることは同じではありません。正常系だけでなく、早期リターン、エラー分岐、条件によるスキップもたどってください。
• ソースが変わったら、正規データを埋め込んでいるドキュメントも更新してください。 派生データ（ワークフロー、スキーマ、設定など）を直接記載しているドキュメントは、気づかないうちに古くなります。ソースと合わせて、該当する埋め込みドキュメントをすべて更新してください。
• コンテキスト復旧後は、サブエージェントの結果を検証してください。 親エージェントが圧縮されている間にバックグラウンドエージェントが完了している場合があります。完了したはずだと信じず、出力を grep して確認してください。
• 対象の全一覧とサブエージェントへの割り当てを照合してください。 カテゴリごとにサブエージェントを並行実行すると、境界上の項目を見落とすことがあります。作業を進める前に、割り当ての和集合を対象一覧と照合してください。
• サブエージェントが引き継ぐ知識は、そのエージェントの .md 定義に書かれた内容だけです。組み込みの Explore ではなく、カスタムエージェント種別を使用してください。 ツールの採用には、権限＋知識＋適用（番号付きワークフロー手順）が必要です。
• サブエージェントの調査結果は最後にまとめてではなく、随時保存してください。 長時間実行されるサブエージェントは、最終書き込み前に打ち切られることがあり、調査結果が失われます。報告ファイルにセクションごとに追記するよう指示してください。
• デバッグ時は修正する前に「どちらの責任か」を確認してください。 呼び出し元（データが誤っている）と呼び出し先（処理が誤っている）をたどり、責任のある層を修正してください。症状が表れる箇所だけを修正してはいけません。
• テスト失敗時は、追跡や編集の前に暫定判定を記録してから調査してください。 次の 5 つの分類をすべて使ってください。SOURCE-WRONG（本番コードが意図に反している）、TEST-WRONG（アサーション／セットアップが古くなっている）、TEST-NOT-OPTIMAL（妥当だが脆弱、または情報量の少ないテスト）、ENVIRONMENT-BLOCKED（外部状態のため判定できない）、AMBIGUOUS（意図や証拠から安全に選べない）。その後、根本原因をたどり、適用される仕様（存在する場合は docs/specs/**）とソースの両方に照らして検証してください。成功を無理に得るために、アサーションを弱めたり、スキップを追加したり、タイムアウトを緩めたり、ソースを変更したりしてはいけません。
• 抽出／リファクタリング後は、削除した名前をすべて grep してください。 主要ファイルの作業完了は、他のファイルもクリーンであることを意味しません。完了を宣言する前に、対象範囲全体で削除したシンボルを一つずつ grep してください。
• 既存の値には意図があると考え、変更したり不具合だと指摘したりする前に、必ず理由を確認してください。 パターンマッチで「誤り」と決めつけると、背景を見落とします。定数／上限／フラグ／しきい値を変更または報告する前に、コメント、git blame、呼び出し元の処理順序（値を正しくする保証は、通常、該当行の直前に実行されるコードにあります）、同じ規約を使っている 2 つ以上の類似した呼び出し箇所を確認してください。理由なしに WHAT（何をするか）だけを記したドキュメントは、根拠が欠けているのではなく、WHY（なぜそうするか）の説明が不足しているということです。検証作業でも、正確な file:line の引用が証明するのは転記が正確であることだけであり、不具合の存在ではありません。
• 最初の出力だけでなく、影響を受けるすべての出力を検証してください。 一つのビルドが成功しても、すべてが成功したとは限りません。複数のスタックにまたがる変更（バックエンド／フロントエンド／テスト／ドキュメント）では、すべての出力を検証してください。
• 近くにあるパターンをコピーする前に、適合性を評価してください。 最も近い例が適合するとは限りません。新しいコンテキストが同じ制約、基底クラス、スコープ、ライフタイムを共有するか確認してください。
• デバッグでは全体を優先し、目についた箇所に飛びつかないでください。 最初に思いついた原因へすぐ飛びつかないでください。前提条件（設定、環境変数、パス、DB、エンドポイント、認証情報、バージョン、DI、データ）をすべて列挙し、それぞれを証拠（推論ではなく grep／クエリ）に照らして検証してください。「何があればこの仮説は否定されるか？」と問い、何も答えられないなら、それは仮説ではありません。最もコストの高い失敗は、バグが一度も疑われていない層にあるのに、「明らか」だと思い込んだ層をさらに深掘りすることです。
• 変更は最小限にし、差分テストを適用してください（コンテキストに合わせて判断）。 2 つのモードがあります。（1）バグ修正 → すべての行がバグに直接関係するようにし、スタイル変更はしないでください。不要になったインポートを削除してよいのは、あなたの変更によって不要になったものだけです。（2）レビュー／機能強化 → 改善を実装し、「主な依頼を超える機能強化：[内容]」と明示してください。黙ってスコープを拡大しないでください。差分テスト：「X を依頼されていなかったとしても、この行は存在していたか？」いいえなら、削除するか明示してください。
• 実装前に曖昧さを明らかにし、黙って解釈を選ばないでください。 複数の妥当な解釈がある場合は、それぞれの工数とともに提示してください。「[依頼] は（1）[N 時間]、（2）[N 時間]のいずれかと解釈できます。どちらが重要ですか？」まずスコープ／形式／量／制約に関する前提を列挙してください。より簡単な方法がある場合は、そのことも伝えてください。黙って選ばないでください。
• [必須の最初のアクション] 応答する前に、必ず適切なスキルまたはワークフローを有効にしてください。 ワークフローカタログとスキル一覧に照らしてタスクを確認し、スキルの呼び出し、または $start-workflow <workflowId> で実行してください。確認する前に回答やコード作成をしてはいけません。省略はプロトコル違反です。
• Why-Review の敵対的な視点は、計画、判断、設計をレビューするときに適用してください。 基本姿勢は VALIDATOR（妥当性を確認する側）ではなく SKEPTIC（懐疑的な側）です。却下された代替案の最も強い論拠を組み立て、述べられた理由を一つずつ逆転させて「何を犠牲にするのか」を問い、上位 2～3 個の前提をストレステストし、プレモーテム（「リリースしたが 3 か月後に失敗した。何が壊れたのか？」）を行い、作成者が見落とした代替案を 1～2 個提示してください。セクションがあるだけでは十分ではありません。重要なのは、因果関係に基づく推論、具体的な軽減策、証拠です。「より良い」や「注意深く監視する」だけでは不十分です。
• 大規模なレビューでは、サブエージェントへのプロンプトで報告書の書き込みを最初に行わせてください。 多数のファイルを扱うサブエージェントは、最終書き込みの前に予算を使い切り、調査結果を失うことがあります。プロンプトは、（1）報告書の書き込みを最初に明示する成果物とする、（2）まとめてではなくファイル／セクションごとに追記する、（3）読み込みで予算を使い切らないようスコープを限定する、という構成にしてください。報告ファイルを残さず文の途中で打ち切られた場合は、同じプロンプトを再試行せず、より狭いスコープで再実行してください。
• コンテキスト圧縮後は、続行する前に以前の各フェーズの結果をすべて再検証してください。 要約が示すのは意図であり、環境の状態（git のインデックス、ファイルシステム、プロセス）ではありません。再開時はまず git status を確認し、変更したファイルを再読込し、ファイルシステムを検証してください。証拠で確認されるまでは、「完了した」という主張もすべて未検証の仮説です。
• OOM／メモリ：行サイズより先に行数を確認してください。 次の順にトリアージします。（1）上限のないクエリ — 条件を設定するトリガーとなる DB フィルターがありませんか？ DB 側にフィルターを移せば、OOM を解消できます。（2）行サイズが大きいですか？ プロジェクションを使えば比例して減らせます。費用対効果では、プロジェクションより行数削減が優先です。
• システムが担う最終結果をアサートし、インフラストラクチャが担う中間状態をアサートしないでください。 非同期処理（キュー／ブローカーへの配信、再試行、バックグラウンドジョブ、キャッシュ、レプリケーション）をテストする場合は、最終的なビジネス／エンティティの状態をアサートしてください。配信の記録、つまり消費／送信ステータス、試行回数、最終エラー、ブローカー、スケジューラー、outbox／inbox テーブル内の行の有無や件数をアサートしてはいけません。この記録は共有インフラストラクチャに存在し、並行して動く任意のプロセス（別のワーカー、2 つ目のレプリカ、残っているローカルコンテナー）から書き込めるうえ、通常は決定的な共有キーが使われます。そのため、こうしたアサーションは気づかないうちにシステムではなく開発者の環境をテストします。単独実行では成功しても、同じブローカー＋データベースをほかの何かが共有した途端に不安定になります。すべてのアサーションで、次の判定の問いを使ってください。「どのプロセスが処理しても、この結果は成り立つか？」いいえなら、代わりに収束後のデータ状態をアサートしてください。系として、プロセスローカルな障害注入やプロセス内テレメトリーを、任意のプロセスが実行する処理のゲートとして使うことはできません。負荷増幅に使ってください（有効化 → 範囲を限定した時間枠 → 無効化 → 収束をアサート）。前提条件として使ってはいけません。
• ドメイン概念を汎用／共有／インフラストラクチャ層に持ち込まないでください。 再利用可能な層（共有ライブラリ、フレームワーク、インフラモジュール）は、利用側に固有のドメイン概念（テナント／顧客／製品 ID、ビジネスエンティティ、機能ルール）を一切参照してはいけません。漏れがコンパイルされ、実行されると、再利用可能なはずの層が一つの利用側と結合していても、レビューで気づかれずに通過してしまいます。共有型からドメイン情報を排除し、サブクラス化／コンポジションを通じて、ドメインフィールド／ロジックを利用側へ移してください。理由：一つの利用側のドメインに結合した層は、もはや再利用可能ではありません。