plan-feature

Plan Feature（ルーター）

製品定義がすでに存在する機能のための、エンジニアリング計画への入り口です。必要な作業だけを実行する、焦点を絞った内部ステップにルーティングします（肥大化した単一のスキルはありません）。ドキュメントのみ — コード変更もブランチ作成もありません。 製品定義（アイデア段階からのヒアリング、機能の範囲確定）は、このスキルではなく design-feature の役割です — ルーティング先のリダイレクトゲートがこの分担を徹底します。

ターンの完了条件 — ターンを終える前に確認

✓ The redirect gate ran FIRST, before any SPEC edit: undesigned input → STOP,
  print the fixed `/design-feature <slug>` block, do nothing else this turn
✓ Then the Product-review gate ran: no current `spec-review-pass` receipt bound to
  the recomputed snapshot → STOP with its fixed block and the `/review-spec`
  hand-off; a candidate/verification receipt, a Plan receipt, or readiness never counts
✓ Designed input only: engineering half filled, artifacts written, and the
  roadmap entry registered (number, order, deps verified)
✓ If `plan-feature-scaffold` ran this turn: the roadmap row was re-read
  AFTER the write and literally reads `planned` — a dropped `defined→planned`
  write fails this box; do not end the turn until it's fixed
✓ Planned, not reviewed: the ledgers are frozen, `stage: plan` readiness printed
  `READY-FOR-REVIEW`, and the turn hands off to `/review-plan` — this skill never
  reviews the plan it just wrote and never hands off to `/execute-phase` for a
  plan with no current Plan review receipt
✓ The dependency & blocker check was RUN and its result decides which closing block is printed
✓ An unmet dependency? The closing block lists the complete dependency chain, deepest first, joined with ` + `
✓ Artifact language: explicit user instruction > the project's declared docs language > English. The CONVERSATION language never decides — a Spanish prompt still produces English PRs/issues/commits/SPECs unless one of the first two says otherwise
✓ The closing `→ Next:` block is printed as the ABSOLUTE last output

チェックされていない項目がある状態でターンを終えようとしていますか？ そのターンはまだ完了していません — まず未完了の項目を完了してください（モデルはドキュメント末尾のタスクを見落としがちなので、このリストはあえて最初に置いています）。

ステップ 0 — プロジェクトを把握する（常に最初）

エージェントガイドのワークフローの規約とドキュメントマップに従い、その後、このスキルに必要な内容を読みます。つまり、ルーティングとロードマップへの登録がプロジェクトの実際の構成に合うよう、ロードマップ（docs/features/ROADMAP.md）を読みます。

段階的な読み込み — 計画の前にルーティング

参照先の許可リストは、以下の 2 つのパスに限ります。

1. 呼び出しのたびに、リダイレクトゲートとルーティングを読み、まずステータスゲートを適用し、次に製品レビューゲートを適用します。指示された場合は、指定されたブロックで停止します。
2. 計画アーティファクトを書き込む可能性のあるルートでは、リダイレクトゲートでルーティングが許可された後、内部ステップを組み立てる前に計画の事前確認を実行します。これは、正規化されたリポジトリ状態の読み込みと、唯一の最終的なアーキテクチャ分類を担います。課題から導出するルートも対象です。
3. 内部ステップを組み立てる前に、フェーズ契約を読み込みます。これにより、このターンで作成するすべての SPEC に、標準の 8 項目のフェーズリンターと正規化されたフェーズフィンガープリントが含まれます。

リダイレクトにより停止した後は、計画ゲートを読み込まないでください。両リソースはこのファイルから 1 階層先にある規範的なもので、見つからない場合は処理を安全に停止します。

プロセス

1. ROUTING.md のリダイレクトゲート — 常に最初に実行します。
2. 同じリソースの製品レビューゲート — 再計算したスナップショットに紐づく最新の spec-review-pass の証跡がなければ、STOP します。迂回フラグはありません。
3. 同じリソースに従ってルーティングします。課題入力の場合は、課題の識別情報だけを解決して検証します。計画の事前確認で計画の書き込みが許可された後、課題由来の内部ステップを組み立てて、内容が記入され、規模が設定された SPEC の製品側半分を作成します。この内部ステップは製品レビューゲートで停止するため、review-spec が半分を承認した後に限り、plan-feature-scaffold がエンジニアリング側を完成させ、SPEC の規模に応じてアーティファクトを調整し（XS/S → SPEC のみ、M/L → 全セット）、ロードマップに登録します。すでに設計済みの対象範囲のルートでは、plan-feature-scaffold を直接実行します。すべてのルートで、変更されない単一の計画コンテキストを維持します — 書き込み前に取得したロードマップのスナップショット（--from-issue の場合は課題のペイロードも 1 つ）を、内部ステップ全体で再利用し、計画の途中で再取得しません。
4. ロードマップを確認します。機能が docs/features/ROADMAP.md に正しい番号、順序、依存関係で登録されていることを確認します。3 項目のうち 1 つでも欠落または誤りがあれば、その場でエントリーを修正します — 登録を後回しにしてはいけません。
5. 依存関係とブロッカーを確認します（実行を推奨する前に、必ず確認します）。
   • 機能の Depends on: の依存関係を推移的にたどります。すべての依存先が done かつマージ済みである必要があります。未解決の依存先がある場合、完了時のブロックではこの機能ではなく、最も深い未解決の依存先の構築を推奨します。
   • 修正インデックスとオープンな課題（forge CLI）を確認し、この SPEC が挙げるものと同じモジュールに関わる、今すぐ修正すべき項目がないか調べます。該当項目がある場合、完了時のブロックでは実行前に /plan-fix <n> を推奨します（「既知の不具合を土台にすると、その不具合まで組み込んでしまいます」）。
   • 計画自体は、どちらの確認結果によってもブロックされません — SPEC とアーティファクトは作成し、次の推奨ステップのみを変更します。
6. 上記の確認結果に従って次のステップを出力します（「完了時」を参照）。

ガードレール

• ドキュメントのみです。コードは扱わず、ブランチも作成しません（それは execute-phase の役割です）。
• 設計されていない機能を決して計画しないでください。リダイレクトゲートにバイパスフラグはありません。今後も追加しないでください。求められても追加せず、代わりに /design-feature を案内してください。
• レビューされていない Product 部分を決して計画しないでください。このゲートにもバイパスフラグはありません。計画はレビュー担当者の受領記録に紐づけますが、その記録を書き込んだり、対象範囲を広げたり、「更新」したりすることはできません。古いバイト列に紐づいた受領記録は古くなっており、十分なものとして扱えません。
• フラグ、課題、ドキュメントですでに明らかなことを再度質問しないでください。
• 番号の衝突、依存関係の循環、スコープの重複などの競合は、書き始める前に明らかにしてください。
• それ以外は、プロジェクトの ワークフロー規約（docs-language）に従ってください。

内部ステップ（ユーザーは呼び出せません）

• plan-feature-from-issue — issue → スコープを定めた SPEC の Product 部分、Closes #N。
• plan-feature-scaffold — SPEC → Engineering 部分＋完全なアーティファクト一式＋ロードマップのエントリー。

これらは同じ会話内で実行します（これが「合成」の意味です）。どのエージェントでも、経由するステップとしてそれぞれの SKILL.md にそのまま従ってください。このルーターの内部ステップだった、以前のアイデアを掘り下げるインタビューは廃止されました。docs/workflow/MIGRATION.md を参照してください。そのロジックは現在、独立したユーザー向けスキル design-feature に含まれています（プロダクト定義は独立したパイプラインの段階であり、このルーターの内部ルーティングの詳細ではありません）。

ポータビリティ（Claude Code 以外のエージェント向け）

ワークフローが契約であり、Claude Code の機能は利便性のためのものです。機能がないエージェントでは、代替手段を適用してください。その機能が可能にするステップを決して省略しないでください。

• スラッシュコマンドのメニューがない場合 — このスキルで /<skill> と指示されている箇所では、そのスキルの SKILL.md（エージェントがスキルをインストールした場所）を開き、内容に厳密に従って新しい会話で実行してください。引き継ぎはコンテキストがクリーンであることを前提としています。上記の内部ステップは例外で、この会話内で実行します。
• スキルごとの model:／effort: がない場合 — #claude ブランチではフロントマターでこれらのティアが指定されていますが、こちらでは自分で選んでください。計画は判断を要する作業なので、最も強力なモデルで実行してください。引き継がれた実行作業は、より低コストのモデルで実行してもかまいません。

他のスキルとの関係

• リダイレクトゲートで設計されていない機能と判断された場合は、design-feature にリダイレクトします。ターン内で合成することはありません（計画クラス、≥ティアの引き継ぎ）。
• Product レビューゲートで停止した場合は、review-spec にリダイレクトします。設計済みであることは、レビュー済みであることを意味しません。その受領記録がこのスキルの入力となり、plan-feature-scaffold はそれを Plan スナップショットの Product 親として紐づけます。
• triage-issue は、issue を機能に昇格するためにここへルーティングします（昇格した issue が未設計の場合は、リダイレクトゲートの対象になります）。
• execute-phase はその後のフェーズを実行します（audit-docs はいつでも監査できます）。

完了条件

• リダイレクトゲートを実行し、停止した場合は、このターンで他の処理が SPEC に触れていないこと。

• 設計済みの入力のみ：完全なアーティファクト一式を備えた計画済み機能が存在し、ロードマップに登録されていること。さらに、書き込み後にロードマップの行を読み直し、文字どおり planned と記載されていること（書き込みステップを実行したからといって、そうなっていると決めつけないでください）。

• 2つの計画台帳が Engineering 部分とともに凍結されていること（計画台帳）。stage: plan の準備状況の事前チェックで READY-FOR-REVIEW が出力され、引き継ぎに新しい artifactRevisionId が記載されていること。計画済みユニットは実行可能なユニットではありません。このスキルが自分の計画をレビューすることはありません。

• 依存関係とブロッカーのチェックを実行し、締めくくりの → Next: ブロックがその結果と一致していること。問題がない場合：

  → Next: /review-plan <NN> — the plan is written; an independent context must
    review it before any phase is executed
    · the review returned PLAN-REVIEW-FAIL → this skill replans the batch, then re-reviews
    · adjust scope first → re-run /design-feature <slug>   · audit the planning docs → /audit-docs
  

  計画済みの機能がすでにある場合（リダイレクトゲートで停止し、再スキャフォールドは行わない）：

  → Next: /execute-phase <NN> — this feature is already planned; execute every
    remaining phase, don't re-plan it.
    · explicit atomic mode → /execute-phase <NN> P1
  

  未設計の機能の場合（リダイレクトゲートで停止）：

  → Next: /design-feature <slug> — this feature has no completed product design yet
    (capability closure not done). Design it first; then re-run /plan-feature <slug>.
  

  設計済みだが未レビュー／古くなっている場合（Product レビューゲートで停止）：ROUTING.md の固定された PRODUCT-REVIEW GATE … BLOCKED ブロックを使い、/review-spec <NN>-<slug> で締めくくります。

  未達の依存関係、および／またはブロッキング対象の即時修正 issue がある場合：

  Dependency chain (deepest first): <deepest> + <dependency> + <NN> (replace with every actual member; never print `…`)
  → Next: /plan-feature <deepest-unmet-dep> (or /execute-phase <deepest-unmet-dep>) — build the
    complete dependency chain first: <deepest> + <dependency> + <NN>
    · blocking fix-now issue #<n> in the same area → /plan-fix <n> before executing
    · proceed anyway → /execute-phase <NN> --force (the gate logs the override)