plan-ci

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 を起点にし、タスクに関連するファイルのみを開いてください。

クイックサマリー

目標： GitHub Actions の CI ログを分析し、特定された問題を修正する計画を作成します。

ワークフロー：

1. 取得 — GitHub Actions から CI ログをダウンロードします
2. 分析 — ビルド／テストの失敗から根本原因を特定します
3. 計画 — CI の問題を修正する実装計画を作成します

主なルール：

• 計画のみ：実装せず、修正計画の作成のみを行います
• CI 固有の問題（ビルド、テスト、環境、Docker、依存関係）に焦点を当てます
• 計画の作成後は、必ず $plan-review を提案してください

懐疑的な姿勢を保ってください。批判的思考と順序立てた思考を適用してください。すべての主張には追跡可能な証拠と確信度（割合）を示してください（確信度は 80％を超える必要があります）。

planning スキルを有効にしてください。

計画のみ — コラボレーション必須

使用しないでください： 手動の計画モード切り替えツール。すでに計画ワークフロー内です。 実装または実行しないでください： コードの変更。 ユーザーと協力してください： 判断が必要な質問をし、推奨案を添えて選択肢を提示してください。 計画の作成後は、必ず $plan-review を実行して計画を検証してください。 次の手順に進む前に、ユーザーに計画の承認を求めてください。

GitHub Actions の URL

$ARGUMENTS

planner サブエージェントを使用して GitHub Actions のログを読み取り、分析して問題の根本原因を特定し、修正を実装するための詳細な計画を提示してください。

計画ファイルの仕様：

• すべての plan.md は、必ず YAML フロントマターで始めてください。

  ---
  title: '{Brief title}'
  description: '{One sentence for card preview}'
  status: pending
  priority: P1
  effort: { estimated fix time }
  branch: { current git branch }
  tags: [ci, bugfix]
  created: { YYYY-MM-DD }
  ---
  

出力： 明確なトレードオフを示した実装アプローチを少なくとも 2 つ提示し、それぞれの長所と短所を説明したうえで、推奨するアプローチを提示してください。

重要なタスク計画の注意事項（必ず従ってください）

• 常にタスク追跡を使用して作業を計画し、多数の小さな ToDo タスクに分割してください。
• 作業品質を確認し、修正や改善点を特定する最終レビューの ToDo タスクを必ず追加してください。
• 必須の最終タスク： すべての計画 ToDo タスクを作成した後、必ず次の最終タスクを追加してください。
  1. タスク：「各フェーズのテスト仕様を作成する」 — すべてのフェーズファイルに TC-{FEATURE}-{NNN} ID を付けた ## Test Specifications を追加してください。機能ドキュメントがある場合は $tdd-spec を使用してください。TDD ファーストモードでは Evidence: TBD を使用してください。
  2. タスク：「$plan-validate を実行する」 — $plan-validate スキルを起動して、ユーザーに重要な質問をし、計画の前提を検証してください。
  3. タスク：「$plan-review を実行する」 — $plan-review スキルを起動して、計画の妥当性、正確性、ベストプラクティスを自動レビューしてください。
  4. タスク：「最終計画に基づいて見積もりを再評価する」 — 完了前の見積もりはスコープの推測に基づいています。フェーズ、TC、決定事項が確定した後、次の作業を行ってください。(a) 確定したフェーズファイルから bottom_up_hours = Σ phase_hours を再算出する。(b) SYNC:estimation-framework に従って likely_days、risk_margin_pct、最小～最大の範囲を再計算する。(c) 現在のフロントマターにある man_days_traditional／story_points と比較する。|delta| > 20% の場合は、フロントマターを更新し、reestimate_delta_pct: <signed> と理由を 1 行で示す reestimate_reason を追加してください。|delta| > 50% の場合は SHOULD-RESCOPE のフラグを立て、実装前にユーザーへ直接質問して伝えてください。

重要な注意事項

重要： スキルカタログを分析し、作業中に必要なスキルを有効化してください。 重要： 出力では簡潔さを優先し、文法にはこだわりすぎないでください。

リマインダー — 計画のみのコマンド

禁止： 手動の計画モード切り替えツールを使用しないでください。 禁止： 実装を開始しないでください。 必須： 計画作成後は必ず $plan-review で検証してください。 必須： 実装を開始する前に、ユーザーに計画の確認を求めてください。 必須： 複数のアプローチがある場合は、推奨案とともにユーザーへ判断を求める質問をしてください。

---

【重要】 作業を始める前に、タスク追跡を使用して、ファイルの読み取りごとのタスクも含め、すべての作業を小さなタスクに分割してください。長いファイルによるコンテキストの喪失を防ぐためです。簡単なタスクでは、スキップしてよいかどうかを AI が必ずユーザーに尋ねてください。

• docs/specs/ — モジュールごとのテスト仕様（既存の TC を読み、計画にテスト戦略を含めてください）

スキルのバリエーション： $plan のバリエーションで、CI／GitHub Actions の失敗分析に特化しています。 AI のミス防止 — すべてのタスクで避けるべき失敗パターン：

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

ネストされたタスクの展開ルール — ワークフローのステップを呼び出す場合、[Workflow] ... の行は親コンテナにすぎません。子スキルによって、フェーズタスクも引き続き表示されます。

1. まず現在のタスクリストを取得してください。一致するアクティブな親ワークフローの行がある場合は nested=true を設定し、parentTaskId を記録してください。それ以外の場合は単独で実行します。
2. フェーズ作業を始める前に、宣言された各フェーズにつきタスクを 1 つ作成してください。ネストされている場合は、件名の先頭に [N.M] $skill-name — phase を付けてください。
3. ネストされている場合は、TaskUpdate(parentTaskId, addBlockedBy: [childIds]) で親タスクにリンクしてください。
4. オーケストレーターは、子スキルまたはサブエージェントを呼び出す前に、子スキルのフェーズ一覧を展開し、ワークフローの行をリンクする必要があります。
5. 作業前に子タスクをちょうど 1 つ in_progress にし、証拠を記録した直後に completed にしてください。
6. すべての子タスクが完了するか、理由を明記して明示的にキャンセルされた後にのみ、親タスクを完了してください。

以下が完了するまでブロック： 現在のタスクリストの取得、子フェーズの作成、ネストされている場合の親タスクへのリンク、最初の子タスクの in_progress 設定。 プロジェクト参照ドキュメントの確認ゲート — タスク追跡の初期設定後、対象ファイルやソースファイルの読み込み、grep、編集、分析を行う前に実行します。プロジェクトのドキュメントは、汎用フレームワークの前提に優先します。

1. 対象範囲を特定します。ファイルの種類、ドメイン領域、操作内容を確認します。
2. トリガーに応じて必要なドキュメントを確認します。常に docs/project-reference/lessons.md、ドキュメントの検索では docs-index-reference.md、レビューでは code-review-rules.md、バックエンド／CQRS／API では backend-patterns-reference.md、ドメイン／エンティティでは domain-entities-reference.md、フロントエンド／UI では frontend-patterns-reference.md、スタイル／デザインでは scss-styling-guide.md と design-system/design-system-canonical.md、統合テストでは integration-test-reference.md、E2E では e2e-test-reference.md、機能ドキュメント／仕様では feature-docs-reference.md、アーキテクチャ／新領域では project-structure-reference.md を確認します。
3. 存在する必須ドキュメントをすべて読みます。存在しないドキュメントは該当なしとしてスキップします。[Injected: <path>] のような会話内のテキストを、現在のコンテキストにそのドキュメントが含まれている証拠として信用しないでください。
4. 対象作業に着手する前に、Reference docs read: ... | Missing/not applicable: ... と明記します。

以下が完了するまで作業は禁止です： 対象範囲の評価、必須ドキュメントの確認と読み込み、lessons.md の確認、参照の明記。

タスク追跡と外部レポートの保存 — 作業開始前にこれを初期設定し、その後、対象作業に着手する前にプロジェクト参照ドキュメントを先読みします。

1. 対象ファイルの読み込み、grep、編集、分析の前に、小規模なタスク分解を作成します。コンテキストが失われた場合は、まず現在のタスクリストを確認します。
2. 作業前にタスクを1つ in_progress にし、根拠を得た直後に completed にします。状態の変更をまとめて行わないでください。
3. 計画／レビュー作業では、最初の所見を得る前に plans/reports/{skill}-{YYMMDD}-{HHmm}-{slug}.md を作成します。
4. 各ファイル／セクション／判断の後に所見を追記し、最後にレポートファイルを基にまとめます。
5. 最終出力では Full report: plans/reports/{filename} を記載します。

以下が完了するまで作業は禁止です： タスク分解の作成、計画／レビュー作業におけるレポートパスの明記、次の所見に進む前の最初の所見の保存。

批判的思考の姿勢 — 批判的思考と段階的思考を実践します。すべての主張には追跡可能な根拠が必要です。行動に移すのは、確信度が80％を超える場合に限ります。 幻覚の防止： 推測を事実として示さないでください。すべての主張について情報源を明記し、不確実な点は率直に認め、出力に誤りがないか自己確認し、独立して相互参照し、自分の確信度にも懐疑的でいてください。根拠のない確信は、あらゆる幻覚の根源です。 逐次的思考プロトコル — 複雑または曖昧な作業に対する、構造化された多段階の推論です。一度きりの推論では危険な、計画、レビュー、デバッグ、アイデアのブラッシュアップに使用します。

次の場合に使用： 複雑な問題の分解 · 修正が必要な適応型計画 · 軌道修正を伴う分析 · 不明瞭または発展中のスコープ · 多段階の解決策 · 仮説主導のデバッグ · 複数領域にまたがるトレードオフの評価。

形式（明示モード — 思考の経過を可視化）：

1. Thought N/M: [aspect] — 1つの思考につき1つの側面を扱い、前提や不確実性を明示します
2. Thought N/M [REVISION of Thought K]: ... — 以前の推論が無効になった場合に使用し、Original / Why revised / Impact を明示します
3. Thought N/M [BRANCH A from Thought K]: ... — 代替案を検討し、判断の根拠を示して結論に収束させます
4. Thought N/M [HYPOTHESIS]: ... に続けて [VERIFICATION]: ... — 実行前に検証します
5. Thought N/N [FINAL] — 検証済みで、重要な側面をすべて扱い、確信度が80%を超えた場合にのみ使用します

必須の締めくくり： 確信度（%）を明記 · 前提を列挙 · 未解決の質問を提示 · 具体的な次のアクションを示す。

停止条件： 重要な判断の確信度が80%未満 → ユーザーに直接質問してエスカレーション · 同じ思考を3回以上修正 → 問題を捉え直す · 分岐が3つを超える → サブタスクに分割する。

暗黙モード： マーカーを付けると回答が煩雑になる場合（推論が正確さに役立つ定型作業など）は、マーカーを表示せずに手法を適用します。

詳細： $sequential-thinking スキル（.claude/skills/sequential-thinking/SKILL.md）を参照してください。実例（api-design、debug、architecture）、高度な手法（螺旋型の洗練、仮説検証、収束）、メタ戦略（不確実性への対応、修正の連鎖）が記載されています。

まず既存コードを理解する — 厳格な必須条件：既存のコードを読むまで、コードの作成、計画、修正を行ってはいけません。

1. 類似パターンを3つ以上検索する（grep/glob）— 根拠として file:line を引用する
2. 対象領域の既存ファイルを読み、構造、基底クラス、規約を理解する
3. .code-graph/graph.db が存在する場合は、python .claude/scripts/code_graph trace <file> --direction both --json を実行する
4. connections または callers_of を使って依存関係を把握し、対象に依存しているものを確認する
5. 複雑なタスク（ファイルが3つ以上）の調査内容を .ai/workspace/analysis/ に記録する
6. 実装前に分析ファイルを読み直す — 記憶だけを頼りに作業してはいけません。— 理由：長いコンテキストではファイルの内容から乖離します。ファイルが信頼できる情報源です
7. 既存パターンが機能する場合、新しいパターンを決して作らない — 完全に合わせるか、逸脱を記録します。— 理由：異なるパターンがコードベースを分断し、将来の読者全員の作業を遅らせます

次の項目が完了するまで作業禁止： - [ ] 対象ファイルを読んだ - [ ] 3つ以上のパターンを grep で検索した - [ ] グラフトレース（graph.db が存在する場合） - [ ] 前提を根拠に基づいて検証した

根拠に基づく推論 — 憶測は禁止です。すべての主張に証拠が必要です。

1. すべての主張について、file:line、grep の結果、またはフレームワークのドキュメントを引用する
2. 確信度を明示する：80%超ならそのまま進める、60～80%なら先に検証する、60%未満なら推奨しない
3. アーキテクチャの変更には、サービスをまたいだ検証が必要です
4. 「十分な根拠がありません」は、妥当であり、期待される回答です

次の項目が完了するまで作業禁止： - [ ] 証拠のファイルパス（file:line） - [ ] grep 検索を実施した - [ ] 類似パターンを3つ以上見つけた `- [ ] 確信度を明示した

証拠なしで禁止される表現： 「明らかに」、「そう思います」、「〜のはずです」、「おそらく」、「これは〜が原因です」 未完了の場合 → 次を出力します："証拠が不十分です。検証済み：[...]。未検証：[...]。" 見積もりフレームワーク — まずボトムアップで見積もり、SP は DERIVED とします。3日以上になりそうな場合は最小値と最大値の範囲で出力します。スタックに依存しません。基準：開発経験3〜5年、1日あたり生産的な作業時間6時間。AI見積もりでは Claude Code とプロジェクトのコンテキストを前提とします。

手法：

1. 影響範囲の確認（下記）— コードとテストのコストに影響します
2. フェーズに分解 → フェーズごとの時間を算出 → bottom_up_hours = Σ phase_hours
3. likely_days = ceil(bottom_up_hours / 6) × productivity_factor
4. リスクマージン（基本値＋加算分）を合計 → max_days = likely_days × (1 + margin)
5. min_days = likely_days × 0.9
6. likely_days ≥3 の場合は範囲で出力します。<3 の場合は単一の値でも構いません（ただしマージンは記録します）
7. man_days_ai = 同じ範囲 × AI による高速化率
8. story_points は SP-Days を使って likely_days から DERIVED します。決して見積もりの基準にしません。乖離が50%を超える場合は、ボトムアップの見積もりを優先します

生産性係数： 足場となるコード＋コード生成＋AI フックが充実している場合は 0.8 · 成熟した標準的な場合は 1.0 · パターンが弱い場合は 1.2 · 新規開発の場合は 1.5

コスト要因のヒューリスティック（作業種別の行を選ぶ前に適用）：

• UI が支配的なのは CRUD／業務アプリの場合です — バックエンドの1.5〜3倍（状態、バリデーション、レスポンシブ対応、アクセシビリティ、仕上げ）
• バックエンドが支配的なのは次の場合のみです： 複数集約にまたがる不変条件、サービス間コントラクト、スキーマ移行、複雑なクエリ／パフォーマンス、新しいイベントフロー

再利用か新規作成か（レイヤーごとの最重要要因）：

UI の段階	コスト
既存画面でコンポーネントを再利用	0.1-0.3d
既存画面にコントロール／列を追加	0.3-0.8d
コンポーネントを組み合わせて新しい画面を作成	1-2d
独自レイアウト／状態／バリデーションの新画面	2-4d
新しい共有／共通コンポーネント（テーマ適用、テスト済み）	3-6d+

バックエンドの段階	コスト
新しい場所でクエリ／ハンドラーを再利用	0.1-0.3d
既存ハンドラー／エンティティの小規模な更新	0.3-0.8d
既存リポジトリ／モデルに新しいクエリを追加	0.5-1d
既存集約に新しいコマンド／ハンドラーを追加（拡張）	1-2d
新しい集約／エンティティ（リポジトリ、バリデーション、イベント）	2-4d
新しいサービス間コントラクトまたはスキーマ移行	各 2-4d
複数集約にまたがる不変条件／複雑なドメインルール	3-5d

ルール： UI＋バックエンド＋テストの各段階を合計し、生産性係数を適用します。再利用できる場合は段階を省略できます — その旨を明記します。

テスト範囲の要因（test_count を明示的に算出してください。「＋テスト」という曖昧な記載が失敗原因の第1位です）：

要因	件数
正常系のユーザージャーニー	ストーリー／AC の主要フローごとに1件
状態遷移	到達可能な遷移 × 許可されたアクター
複数エンティティの状態の組み合わせ	state(A) × state(B) — 到達可能な組み合わせのみ。直積ではありません
認可マトリクス	(所有者、非所有者、権限昇格済み、未認証) × 各変更操作
バリデーションルール	必須フィールド／境界値／形式／フィールド間チェックごとに1件
UI の状態（新しい画面／ダイアログごと）	正常、読み込み中、空、エラー、一部表示 — 存在する状態のみ
異常系／不変条件	違反可能な業務ルールごとに1件

テスト段階（従来方式、セットアップ＋アサーション＋不安定さを含む）	コスト
1-5 件、フィクスチャを再利用	0.3-0.5d
6-12 件、新しいフィクスチャ1つ	0.5-1d
13-25 件、複数エンティティのセットアップ	1-2d
26-50 件、または新しい状態遷移の網羅	2-3d
>50 件、または E2E ジャーニー全体	3-5d

テストの倍率： 新しいフィクスチャ／シード用ハーネス +0.5d · サービス間／バスのアサーションは各 +0.3d · UI E2E は ×1.5 · 新しいロールごとに +1-2 件

影響範囲（必須の事前確認 — コードとテストの両方に影響）：

1. 直接変更するファイル／コンポーネント — 件数
2. そのうち「複雑なもの」（>500 LOC、複数ハンドラー、中心的、頻繁に変更されるもの）— 件数
3. 下流の利用者（呼び出し元、イベント購読者、サービス間）— 一覧
4. 共有／共通コードへの変更（複数アプリに影響）— yes/no
5. 回帰テストの範囲 — 再テストが必要な領域

ルール： 複雑な箇所に触れる場合は risk_factors に追加します。下流の利用者ごとに回帰テストを +1-3 件追加します。影響範囲が5領域を超える、または複雑な箇所が2つを超える場合は、見積もり前に SPLIT を再検討します。

リスクマージン（最大値を決定）：

likely_days	基本マージン
<1d 軽微	+10%
1-2d 小規模な拡張	+20%
3-4d 実質的な機能	+35%
5-7d 大規模	+50%
8-10d 非常に大規模	+75%
>10d	+100% AND 分割を推奨

リスク要因の加算分（加算方式 — risk_factors に列挙）：

要因	+マージン
touches-complex-existing-feature（>500 LOC、複数ハンドラー、中心的）	+20%
cross-service-contract の変更	+25%
schema-migration-on-populated-data	+25%
new-tech-or-unfamiliar-pattern	+30%
regression-fan-out（再テストが必要な下流領域が3つ以上）	+20%
performance-or-latency-critical	+20%
concurrency-race-event-ordering	+25%
shared-common-code（複数の利用者／アプリ）	+25%
unclear-requirements-or-design	+30%

上限ルール： マージンの合計が100%を超える場合は、作業を停止して分割します（2倍を超える水増しは不誠実です）。likely_days ≥5 でマージンが15%未満の場合は、過小見積もりです。範囲を広げてください。

作業種別の上限（likely_days の厳格な上限）：

作業種別	最大 SP	最大 likely
単一フィールド／設定フラグ／スタイル修正	1	0.5d
既存モデルにプロパティを追加し、既存 UI にバインド	2	1d
拡張エンドポイント＋軽微な UI コントロール（ボタン／メニュー／列）、フィクスチャを再利用	3	2-3d
拡張エンドポイント＋新しい UI 表面、または複数レイヤーの拡張＋新しいドメインルール＋テストファイル2つ以上	5	3-5d
新しいモデル／集約、移行、モジュール間コントラクト、重いテスト（>1.5d）、または新しい UI＋無視できないバックエンド	8	5-7d
新しい UI 表面＋（新しい集約、移行、またはサービス間コントラクト）	13	分割を推奨
サービス間コントラクト＋移行の組み合わせ	13	分割を推奨
これを超える場合	21	分割必須

SP→日数（検証専用）： 1=0.5d/0.25d · 2=1d/0.35d · 3=2d/0.65d · 5=4d/1.0d · 8=6d/1.5d · 13=10d/2.0d（従来方式／AI の likely） AI による高速化： SP 1≈2倍 · 2-3≈3倍 · 5-8≈4倍 · 13以上≈5倍。AI コスト = (code_gen × 1.3) + (test_gen × 1.3)（レビューのオーバーヘッド30%）。

必須のフロントマター：

story_points: <n>
complexity: low | medium | high | critical
man_days_traditional: '<min>-<max>d' # likely が3日以上の場合は範囲、3日未満の場合は '<N>d'
man_days_ai: '<min>-<max>d'
risk_margin_pct: <n> # 基本値＋加算分
risk_factors: [touches-complex-existing-feature, regression-fan-out] # 加算要因の選択肢から指定。該当なしの場合は []
blast_radius:
    touched_areas: <n>
    complex_touched: <n>
    downstream_consumers: [list or count]
    shared_common_code: yes | no
estimate_scope_included: [code, integration-tests, frontend, i18n, docs]
estimate_scope_excluded: [unit-tests, e2e, perf, deployment, code-review-rounds]
estimate_reasoning: |
    以下を含む5〜7行：
    (a) UI の段階 — 適用した行
    (b) バックエンドの段階 — 適用した行
    (c) テスト範囲 — 要因ごとのケース内訳、ファイル数、フィクスチャ、段階の行
    (d) コスト要因 — 支配的な段階とその理由
    (e) 影響範囲 — 変更箇所、複雑な箇所、回帰テスト範囲
    (f) リスク要因 — マージンの要因となるものの一覧と、さらに大きく／小さくならない理由
    例：「UI：Form/Table/Dialog を組み合わせて新画面を作成（約1.5d）。バックエンド：既存集約に新しいコマンドを追加し、
    バリデーションとリポジトリを再利用（約1d）。テスト：遷移4件 × 2アクター＋バリデーション3件＋UI 状態2件 = 13件、
    新しいフィクスチャ1つ → 13-25 件の段階で約1.5d。要因：UI の組み合わせと新しい状態。影響範囲：4領域、複雑な箇所1つ。
    リスク：基本値35%＋複雑な箇所への変更20% = 55% → 最大3.9d → 範囲2.5-4d。」

妥当性のセルフチェック：

• likely_days ≥3d なのに単一の値になっている？ → 不採用。必ず範囲にする

• likely_days ≥5d なのにマージンが15%未満？ → 過小見積もりです。範囲を広げる

• マージンが100%を超えている？ → 停止して、バッファを増やすのではなく分割する

• 既存の複雑な機能に触れるのに、(c) に回帰テストの予算がない？ → 不採用

• 影響範囲が5領域を超える、または複雑な箇所が2つを超えるのに、分割の検討がない？ → 不採用

• 既存モデルと既存 UI への追加だけ？ → テストが1.5dを超えない限り SP は3を上限とする

• 新しい UI 表面（ページ／複雑なフォーム／ダッシュボード）がある？ → バックエンドが単一エンドポイントでも SP 5以上

• バックエンドにサービス間連携／移行／複数集約がある？ → UI に関係なく SP 8以上

• bottom_up_hours / 6 と SP-Days の乖離が50%を超えている？ → ボトムアップの見積もりを優先し、SP を下げる

• テストがない場合に SP が1段階以上下がる？ → テストが支配的な要因です。明記する

• 推論で UI とバックエンド、影響範囲、リスク要因に触れている？ → 不足があれば追加する 計画の品質 — 各計画フェーズには、必ずテスト仕様を含める必要があります。

1. すべてのフェーズファイルに、TC-{FEATURE}-{NNN} IDを含む ## Test Specifications セクションを追加する
2. すべての機能要件を1つ以上のTCに対応付ける（または根拠を明記して明示的に TBD とする）
3. TC IDは TC-{FEATURE}-{NNN} 形式に従う。参照はIDで行い、内容全体を埋め込まない
4. 新しいワークフローステップを始める前に、現在のタスクリストを呼び出し、フェーズファイルを読み直す
5. コンテキスト圧縮時は、まず現在のタスクリストを呼び出す。タスクを重複して作成しない
6. 完了とする前に、フェーズごとにTCの充足を検証する（証拠は file:line とし、TBDにしない）

モード： TDD優先 → 既存TCを Evidence: TBD として参照。実装優先 → TBDを使用し、後から $tdd-spec で補完。

反復的なフェーズ品質 — 計画の前に複雑度をスコア化します。

複雑度の指標： 変更ファイル数が5超で+2、サービス間にまたがる場合は+3、新しいパターンの場合は+2、DBマイグレーションの場合は+2 スコアが6以上の場合 → 必ずフェーズに分解します。各フェーズの条件：

• 変更ファイル数は5以下
• 工数は3時間以下
• サイクルに従う：計画 → 実装 → レビュー → 修正 → 検証
• フェーズNの検証に合格してから、フェーズN+1を開始する — 理由：未検証のフェーズを土台にすると、後続でエラーが累積するため

フェーズの成功条件 = すべてのTCが合格 + code-reviewerエージェントの承認 + CRITICALな指摘がないこと。

• 必須・重要 各フェーズにTC IDを含む ## Test Specifications を追加します。タスクを新しく作成する前に、現在のタスクリストを呼び出してください。

• 必須・重要 すべての主張に file:line の証拠を示してください。確信度が80%超の場合に実行し、60%未満の場合は推奨しないでください。

• 必須 見積もり：ボトムアップで算出したフェーズごとの時間を man_days_traditional の算出に使用します（Σh/6 × productivity_factor）。SPはそこから算出します。通常、UIのコストが支配的です。新しいUIサーフェス（ページ／複雑なフォーム／ダッシュボード）を追加する場合は、SPを1段階引き上げます。Frontmatterには story_points、complexity、man_days_traditional、man_days_ai、estimate_scope_included、estimate_scope_excluded、estimate_reasoning（UIとバックエンドのコスト要因）を必ず含めます。既存のモデルと既存のUIへの追加の場合、テスト範囲が1.5日を超えない限り、SPの上限は3です。SPが13の場合は分割することを推奨し、21の場合は必ず分割します。

• 必須・重要 複雑度を最初にスコア化します。スコアが6以上の場合は分解します。各フェーズで、計画 → 実装 → レビュー → 修正 → 検証の順に進めます。省略は禁止です。

必須 批判的思考を適用します。すべての主張に追跡可能な証拠が必要であり、確信度が80%を超える場合に実行してください。幻覚防止：推測を事実として提示しないでください。

必須 sequential-thinkingを適用します。複数ステップでは Thought N/M を使用し、REVISION/BRANCH/HYPOTHESISマーカーと、より正確な確信度%を記します。$sequential-thinking スキルを参照してください。

必須 AIのミス防止策を適用します。デバッグでは全体を先に確認し、責任のあるレイヤーで修正し、コーディング前に曖昧さを明らかにし、コンテキスト圧縮後にファイルを読み直してください。

• 必須 対象作業に着手する前にタスク追跡を初期化します。タスクは一度に1つずつ遷移させます。

• 必須 計画／レビューの指摘事項を段階的に plans/reports/ に保存し、ディスク上の内容をもとにまとめます。

• 必須 タスク追跡の初期化後、対象／ソース作業の前に、指定されたプロジェクト参照ドキュメントを読み、「Reference docs read: ...」と記載します。

• 必須 必ず lessons.md を含めます。プロジェクトの規約は一般的な既定値より優先されます。

• 必須 親ワークフローの行は、子フェーズの追跡の代わりにはなりません。ネストされている場合はフェーズを展開し、親にリンクします。

• 必須 オーケストレーターは、呼び出し前に子スキルのフェーズを事前展開します。[N.M] $skill-name — phase のプレフィックスと、同時に in_progress にするタスクは1つだけというルールを使用します。

最後のリマインダー

• 必須・重要・必ず注意 作業を始める前に、タスク追跡を使って作業を小さな TODO タスクに分割してください
• 必須・重要・必ず注意 新しいコードを作成する前に、コードベース内で類似パターンを 3 件以上検索してください
• 必須・重要・必ず注意 すべての主張について file:line の根拠を示してください（信頼度が 80% を超える場合に実行してください）
• 必須・重要・必ず注意 作業の品質を確認するための最終レビュー用 TODO タスクを追加してください
• 必須・重要・必ず注意 計画のフロントマターに「Test Specifications」セクションと story_points を含めてください

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

Hookless Prompt Protocol Mirror（自動同期）

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

[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 を読み、そこに記載されているプロジェクトリファレンス文書を開いてください。この共有コンテキストとローカルのドキュメントが利用できる場合は、サポートされている任意の 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] ワークフローやスキルの手順を実行する前に、計画したすべての手順についてタスク追跡を作成または更新してください。その後、各手順の開始時と完了時に、タスク追跡の内容を同期してください。