plan-feature-scaffold

Plan Feature — Scaffold（内部）

設計済みの機能を、フェーズごとの実行にすぐ着手できる完全な計画成果物一式にします。SPEC のエンジニアリング部分のみを作成します。製品部分（目標、背景、スコープ、機能の完結性）はすでに存在し、このスキルの実行前に designed としてマークされています（plan-feature のリダイレクトゲートによって保証されます）。ドキュメントのみ — コードは変更しません。

使用するタイミング

• plan-feature ルーターは、機能の製品部分が designed になった後にこのスキルを呼び出します。呼び出し元は design-feature、plan-feature-from-issue、またはスコープがすでに定まった slug／SPEC です。このスキルは、docs/features/<NN>-<slug>/SPEC.md のエンジニアリング部分とフォルダーの残りの部分を作成し、その後ロードマップを更新します。

製品の定義（それは design-feature の役割です）、コードの作成（それは execute-phase の役割です）、または実装するかどうかの判断（それは plan-feature ルーター／triage-issue の役割です）には使用しません。

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

エージェントガイドのワークフロー規約とドキュメントマップに従い、その後、このスキルに必要な情報を読みます。機能 SPEC のテンプレート、ロードマップ（番号付け／順序／依存関係）、成果物一式の形式を確認するための最近の機能フォルダー 1～2 件、そしてマップが示すアーキテクチャ／ドメインのドキュメントを確認します。テンプレートまたはロードマップがない場合は、エージェントガイドに基づいて進め、その前提を明記します。

段階的な読み込み — 把握してからスキャフォールドする

参照許可リストに含まれるパスは 1 つだけです。ステップ 0 の後、完全なスキャフォールド手順を読み、実行してください。この手順が、製品部分のゲート、成果物の規模調整、ロードマップの遷移、再読み込み、固定の完了報告を担います。フェーズ契約は、8 項目のフェーズ lint と正規化されたフェーズフィンガープリントを担います。

このリソースは規範的で、このファイルから 1 ホップ先にあります。リソースが見つからない場合は停止してください。フェーズや完了報告の文言を記憶から再構成してはいけません。

検証契約は、ACCEPTANCE.md のスキーマ、検証の段階、弱体化防止ルールを担います。エンジニアリング計画の完成後、planned として登録する前に参照してください。

調査と参照元の追跡（計画段階）

• 条件付きのウェブ調査。 計画段階の調査は、範囲を限定した質問（ROWS.md の Q1～Q5）にリポジトリ内の根拠から回答できない場合にのみ実施します。フェーズを出力する前に、ウェブ調査をちょうど 1 回行い、返された内容を根拠の行（URL とアクセス日）として固定します。リポジトリ内で回答できる質問を再取得してはいけません。
• 参照元の追跡は必須。 影響を受けるコードは、シンボル／参照検索で特定します。環境で利用できる場合は LSP／serena を使い、それ以外は grep を使います。影響範囲は必ずその検索結果から導き出し、モデルの記憶に頼ってはいけません。追加または変更するコードは呼び出し元を壊す可能性があるため、計画ではその呼び出し元を明記する必要があります。

ガードレール

• ドキュメントのみ。ソースの編集、マイグレーション、依存関係の追加は禁止です。
• アーキテクチャを尊重します。レイヤーのルール（内側のレイヤーから外側のレイヤーをインポートしない）と、ドキュメントマップに記載されたドメイン／i18n／SEO／a11y のルールに従います。
• アーキテクチャ上の不変条件。 計画の事前確認は、正規化されたリポジトリ状態の読み込みと、計画全体に対する最終的なアーキテクチャ分類を 1 回だけ行います。ここでそれを参照してください。存在しない場合も処理を続けられます。その場合は、エンジニアリング部分に n/a: no project invariants declared と記録します。適用されるルールごとに、その ID、リポジトリ内の根拠、および preserves | violates | introduces | changes の分類を ### Architecture impact に記録します。フェーズを作成できるのは preserves のみです。それ以外の分類では、プロジェクトで定められた権限者を通じて明示的なアーキテクチャ上の判断を求めるため停止します。これは計画全体の完成後に限ります。フェーズのタスクに変換したり、製品部分から推測したりしてはいけません。
• 競合（番号の衝突、依存関係の循環、スコープの重複）は、書き始める前に提示します。書いた後に提示してはいけません。
• それ以外は、プロジェクトのワークフロー規約（ブランチ／PR、ドキュメントの言語）に従います。

他のスキルとの関係

plan-feature ルーターから呼び出されます（design-feature / plan-feature-from-issue がプロダクト側を設計した後、または設計済みのスコープ付きスラッグ／SPECに対して直接呼び出されます）。P1では execute-phase に引き継ぎます。audit-docs はいつでも監査できます。

完了条件

• docs/features/<NN>-<slug>/ が存在し、SPECのエンジニアリング側と ACCEPTANCE.md、およびスケールに応じたすべての計画成果物が記入済みです。プロダクト側は design-feature / plan-feature-from-issue が作成した内容から変更されていません。
• ロードマップに、正しい番号、順序、依存関係で機能が記載され、 ステータスが planned になっています（このスキルが担当する defined → planned の更新です）。 更新後に再読み込みして確認済みであること。実行しただけで確認済みと見なしてはいけません。
• コードは変更されていません。不明点は decisions.md に記録されています。