plan-feature-from-issue

機能の計画 — Issue から（内部用）

機能リクエストの Issue をプロジェクトの計画成果物に変換し、Issue → SPEC → PR（Closes #n）の明確な追跡経路を維持します。SPEC の製品部分（design-feature が使用するのと同じ二部構成の規約）を作成し、引き継ぎ前に機能の網羅性を満たす必要があります。内容の薄い Issue でも、この要件を回避することはできません。

このスキルは製品部分で終了します。 設計後、対象は独立した製品レビューのために review-spec に進みます。エンジニアリング計画は別の権限者が担当します。作成したばかりの設計と同時に plan-feature-scaffold を組み込むことは、この分離によって防ごうとしている迂回行為です。製品部分の作成者が、それを基に構築を始める準備ができていると判断してはなりません。

使用するタイミング

• 入力が新しい製品機能について説明する GitHub Issue（または --from-issue N）の場合、plan-feature ルーターがこのスキルを呼び出します。

Issue がバグまたは技術的負債の場合は、ここで停止して適切な手順に振り分けます。まず triage-issue で分類し、次に plan-fix と execute-phase --fix を実行してください。このスキルの対象は、真の機能だけです。

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

エージェントガイドのワークフロー規約とドキュメントマップに従い、その後、このスキルに必要なものを読みます。機能 SPEC のテンプレート、ロードマップ、Issue／PR のテンプレート（.github/ISSUE_TEMPLATE/、.github/PULL_REQUEST_TEMPLATE.md）を確認し、SPEC がレビュアーの期待する項目を反映するようにします。次に、Issue を読みます（プロジェクトのワークフロー規約に記載された forge CLI を使用します。例では gh を使用します）。

gh issue view <N> --json number,title,body,labels,state,comments

プロセス

1. 最初に分類します。 機能であることを確認します。不具合、リグレッション、重複コード、パフォーマンス上の負債を説明している場合、または「修正時期／発生条件」に関する節がある場合は機能ではありません。triage-issue に引き継ぎます。判定結果を明示してください。

2. 言語を統一します。 プロジェクトのドキュメント言語（このリポジトリでは 英語）で書かれていない場合は、成果物を作成する前に翻訳します。

3. ロードマップに対応付けます。 次の番号とスラッグを割り当てます。依存関係、既存機能との競合、結合や移行のリスク、既存機能の拡張として扱うべきかを特定します。

4. プロダクト側の不足を先回りして補います。 課題を、完全な SPEC の プロダクト側に必要な項目（目標、対象範囲と対象外、ビジネス目標、ドキュメントマップに沿った i18n／SEO／a11y／価格設定、機能に UI がある場合は UI デザインの参考資料）と照らし合わせます。また、design-feature のヒアリングで使われる同じ固定の 曖昧さ評価基準を確認します。影響を受けるユーザー／ロール・エラーとエッジケース・データ形状・境界と制限・対象外・成功基準の各項目を埋めるか、明示的に n/a: <reason> とします。安全に既定値を設定できない実質的な不足があれば、ユーザーに1ターンにつき1つだけ質問し、複数の質問をまとめないでください。質問にはそれぞれ推奨する既定値を添えます。課題やドキュメントですでに回答されていることは尋ねないでください。構造的な引き継ぎ基準： 課題とそれまでの回答から埋められない評価項目が3つ以上残る場合は、ここでのヒアリングを中止し、機能を design-feature に引き継ぎます（以下の「情報不足の課題に関するルール」に固定条件を加えたものです）。

5. 機能の網羅性を満たします。 design-feature が使用する同じ固定チェックリストを確認し、SPEC の ## Capability closure と ## Acceptance criteria に記録します。エンティティごとに、各 CRUD と状態遷移について UI、API、テストを揃えるか、明示的に n/a: <reason> とします。機能ごとにエントリーポイントと ACL を記録し、ロールごとに、どこで割り当て、取り消し、閲覧されるかを記録します。情報が不十分な課題を使って、このゲートを回避することはできません。 不足があって網羅性を満たせない場合は、design-feature に引き継ぎます（Guardrails に従い、このスキルと同等以上のティアの場合に限り、このターン内で組み合わせます。それ以外の場合は run /design-feature <slug> と引き継いで、ここで終了します）。網羅性が空疎なまま designed としてはなりません。

6. 規模を見積もります。 SPEC テンプレートで定義されている基準に従って XS / S / M / L を見積もり、SPEC に記録します。XS／S の場合、計画成果物は SPEC のみです（単一パスで実行します）。M／L の場合は成果物一式を用意します。L の場合は分割を提案します。

7. SPEC のプロダクト側を作成します。 内容を埋め、網羅性を満たしたら ## Design status: designed と記載します。ロードマップに行がない場合は idea で追加し、同じ編集内で defined に設定します。これは design-feature が担う idea → defined の遷移ですが、このスキルが網羅性を満たす場合はここで実施します。次に、内部の evidence-grounding 機能による stage: spec の準備状況チェックを実行し、現在の artifactRevisionId を生成して、そこで終了します。このスキルはエンジニアリング側には進まず、ロードマップの行を defined より先に進めることも、このターンで plan-feature-scaffold を組み立てることもありません。plan-feature ルーターがスキャフォールドを作成できるのは、review-spec がこれらの正確なバイト列に紐付く最新の spec-review-pass レシートを返した後に限られます。

8. 追跡可能性をつなぎます。 SPEC に #N を記録します。PR 本文には Closes #N を含め、マージ時に課題がクローズされるようにします。

9. 引き継ぎ — 以下をそのまま返します（ルーターへの固定完了レポート）：

   ISSUE #<N> → SPEC <slug> — size: <XS|S|M|L>
   Verdict: feature (not bug/debt — else this would have routed to triage-issue)
   Gaps closed: <n> asked / <n> defaulted (logged)   Closure: designed | handed to design-feature
   Readiness: READY-FOR-REVIEW | NEEDS-EVIDENCE | NEEDS-DESIGN   Artifact revision: <id>
   Traceability: Closes #<N> wired
   → review-spec next (engineering planning is gated on its receipt; do not scaffold here)
   

ガードレール

• イシューの範囲を黙って広げないでください。追加案として提示してください。
• ここではフィーチャーブランチを作成したり、コードを書いたりしないでください。
• ここではエンジニアリング作業を計画しないでください。 Engineering 半分も、フェーズも、 defined → planned への昇格も、同一ターン内での plan-feature-scaffold の組み込みも行いません。 このスキルが作成する Product 半分は、まず review-spec によるレビューを受ける必要があります。 readiness が READY-FOR-REVIEW であっても、そのレビューを受けたことにはなりません。
• Closes #N のリンクを残してください。イシューから生まれたフィーチャーでは、必ずそのイシューをクローズする必要があります。
• Capability closure の行が空欄のまま ## Design status: designed を記載してはいけません。 design-feature も同じルールに従います。内容の薄いイシューは、完了したように装うのではなく、引き継ぎます。
• 組み込みレベル。 内容の薄いイシューに対して、同一ターン内で design-feature を組み込めるのは、このスキルが design-feature 以上のレベル（計画クラス — 最も強力なモデル／最高の労力）で実行されている場合に限ります。 それ以外の場合は、能力不足の状態で進めず、run /design-feature <slug> を実行するよう引き継いでください。
• それ以外は、プロジェクトの Workflow conventions（ブランチ／PR、ドキュメントの言語）に従ってください。

アーキテクチャ上の不変条件

planning preflight は、正規化されたリポジトリ状態の読み取りと、計画全体に対する唯一の最終的なアーキテクチャ分類を担います。Product 半分を書く前に、ここでその結果を使用してください。該当する不変条件ルールごとに、ID とリポジトリ内の根拠を示し、イシューの提案を preserves、violates、introduces、changes のいずれかに分類してください。designed と記載できるのは preserves の場合のみです。それ以外の分類では、プロジェクトが定める権限者を通じて、明示的なアーキテクチャ上の判断を得るまで作業を停止してください。計画全体ができあがる前に判断を求めたり、イシュー本文、SPEC、またはテストの合格から判断を推測したりしてはいけません。

他のスキルとの関係

• triage-issue — バグ、フィーチャー、または保留のいずれにするかを判断します。不確かな場合は呼び出してください。
• plan-fix — バグ／技術的負債のイシューに対応する修正側の姉妹スキルです。
• design-feature — このスキルでは Capability closure を安全に完了できない内容の薄いイシューを受け取ります。どちらも同じ形式で SPEC の Product 半分を作成します。
• review-spec — イシュー由来のすべてのフィーチャーで必須となる次のステップです。このスキルが作成した Product 半分をレビューし、受領を記録します。
• plan-feature-scaffold — review-spec の合格後に限り、後から Engineering 半分を作成します。このスキルから呼び出すことはありません。
• execute-phase — フェーズを実行します。その PR には Closes #N を記載します。

完了条件

• Product 半分を埋めた SPEC が存在し、roadmap に defined として登録され、stage: spec の readiness ブロックが出力され、現在の artifactRevisionId が記録されていること。
• Capability closure が満たされていること（または、完了したように装わず、イシューを design-feature に引き継いでいること）。また、## Design status が正確であること。
• ## Design status: designed を記載した場合、roadmap の行のステータスが defined であること（新規の場合は最初に idea として追加）。空欄の closure を defined にしてはならず、designed を記載した後に idea のまま残してもいけません。
• スキャフォールディングを一切行っていないこと。Engineering 半分、フェーズ、planned の書き込みはなく、確定したレポートが /review-spec に引き継がれること。
• #N が記録され、PR の計画に Closes #N が含まれていること。
• スコープの不足についてユーザーと確認・解決しており、推測で補っていないこと。