plan-feature

機能計画ワークフロー

機能のアイデアを、スコープを絞り、評議会の合意を得て、意思決定記録を文書化したうえで、承認済みの実装計画へと導きます。このスキルでは、あらゆる段階で前提に異議を唱え、厳しい質問を投げかけ、異論を述べます。評議会での審査前、評決後、最終承認前がその対象です。目的は、最初のアイデアに追認を与えることではなく、可能な限り最善の計画にたどり着くことです。

注意

スコープの境界：このスキルが作成するのは、計画、意思決定記録、GitHub イシュー、および適切なフェーズ割り当てでの製品ロードマッププロジェクトへの登録です。アプリケーションコードの記述、コンポーネントの作成、データベーススキーマの変更、テストの実行、実装用ブランチの作成、ビルド作業は行いません。計画の承認後にユーザーがビルドを始めるよう求めた場合は、/build-feature <issue-number> の実行を案内してください。自分で実装を始めてはいけません。

ステップ 1：機能の背景情報を収集する

ユーザーに次の内容を説明してもらいます。

• 何をする機能か（ユーザー向けの動作）
• 誰を対象とするか（ターゲットユーザー）
• なぜ重要なのか（ビジネス上またはプロダクト上の価値）
• 制約条件（時間、技術、予算、依存関係）

ユーザーが GitHub イシュー番号を提示した場合は、イシューの詳細を取得します。

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

元のイシュー番号を記録してください。GitHub イシューを起点に計画を開始した場合は、ステップ 3、5、7 で後から更新できるよう、その番号を保存します。

すでに計画済みかどうかの確認

イシューに build-ready ラベルが付いている場合は、すでに /plan-feature を実施済みで、計画が十分と判断されています。続行する前にユーザーに警告します。

警告

イシュー #<number> にはすでに build-ready ラベルが付いています。これは、以前に /plan-feature が実行されたことを意味します。再実行すると、新しい意思決定記録が作成され、実装イシューが重複して作成される可能性があります。

ユーザーに次のどちらにするか確認します。

• (a) それでも続行する（要件が大幅に変わった場合などに、最初から計画を立て直す）
• (b) 停止して既存の計画を使う（代わりに /build-feature <number> を実行する）

ユーザーが明確に選択するまで、ステップ 1 より先に進んではいけません。

小規模スコープのトリアージ

背景情報を収集した後、そのイシューに評議会のフルワークフローが本当に必要かを評価します。すべてのイシューに、プロダクト評議会、機能評議会、意思決定記録、実装イシューが必要なわけではありません。次のすべてに該当する場合、そのイシューは小規模すぎる可能性があります。

• 推定サイズが XS または S（1〜2 日の作業）
• アーキテクチャ上の判断を伴わず、変更対象が 3 ファイル以下
• フロントエンドの変更がない（またはごくわずかな変更のみ）
• データベーススキーマの変更がない
• 新しい API エンドポイントがない（既存の起動時コード／設定コードの変更は問題ありません）
• 実装方法が明確で曖昧さがない — 実質的に正しい方法が 1 つしかない

イシューがこれらの条件に該当する場合は、小規模スコープ向けのバイパスをユーザーに推奨します。

ヒント

このイシューは、小規模なため、/plan-feature の評議会フルワークフローを省略できそうです。スコープは明確で、実装も簡単です。2 つの評議会を開き、意思決定記録を作成すると、得られる価値よりも負担のほうが大きくなります。

推奨する対応：build-ready ラベルを直接追加し、実装のために /build-feature <number> または /build-api <number> を実行します。

ユーザーに次のどちらにするか確認します。

• (a) build-ready を適用して停止する（ユーザーは別途 /build-feature または /build-api を実行します）
• (b) それでも /plan-feature のフルワークフローを続行する（前例やポリシー上の理由で評議会の意見を求める場合など）

ユーザーが (a) を選んだ場合：

1. イシューに build-ready ラベルを追加します
2. トリアージ中に決定した内容（使用するアプローチ、承認された値、変更対象のファイルなど）を記録した、簡潔な実装コンテキストのコメントを追加します
3. 停止します — ステップ 2 以降に進んではいけません

ユーザーが簡潔な説明を提示している場合でも、それで十分です。ただし、内容をそのまま鵜呑みにしてはいけません。ステップ 2 に進みます。

ステップ 2：批判的な分析と検討

この機能をプロダクト評議会に提出する前に、懐疑的なアドバイザーとして行動してください。あなたの役割は、アイデアを厳しく検証し、ユーザーが可能な限り最善の機能にたどり着けるよう支援することです。

前提を検討する

機能リクエストに含まれる暗黙の前提を特定し、問い直してください。

• 問題の妥当性：正しい問題を解決しようとしていますか？ユーザーが示した問題は、より根本的な課題の兆候ではありませんか？
• 解決策との適合性：これが最善の解決策でしょうか？それとも、最初に思いついたアイデアに固執していませんか？実行可能であれば、代替案を 1～2 件提示してください。
• スコープ拡大のリスク：ユーザーは必要以上のことを求めていませんか？中核となる仮説を検証するために必要な最小限のものは何ですか？
• タイミング：プロジェクトの現状を踏まえ、今これを構築すべきでしょうか？先に満たすべき前提条件や依存関係はありますか？

確認の質問をする

提案の不足や弱点を明らかにする、要点を突いた質問を 2～4 件してください。例：

• 「[エッジケース] の場合、どうなりますか？……について検討しましたか？」
• 「X とおっしゃいましたが、既存の Y との連携はどうなりますか？」
• 「ユーザーが現在使っている回避策は何ですか？実際にどれほど不便なのでしょうか？」
• 「開発期間が半分しかない場合、何を削りますか？」

推奨事項を提示する

分析に基づいて、次の内容を提示してください。

• 提案の優れている点（有効な部分を評価する）
• 懸念点（リスク、見落とし、過剰な設計）
• 変更すべき点（漠然とした警告ではなく、具体的な提案）
• 別の捉え方（異なる方法で問題を解決できる場合）

チェックポイント：批判的な分析と質問をユーザーに提示してください。プロダクト評議会に進む前に、ユーザーの回答とスコープ調整を待ってください。安易に承認してはいけません。回答が懸念を解消しない場合は、再度異議を唱えてください。

ステップ 3：プロダクト評議会を招集する

.claude/councils/product-council.md からプロダクト評議会のテンプレートを読み込み、6 人のメンバーそれぞれの視点から機能を評価してください。

モデルの選定：エージェントのモデル仕様を Task ツールのパラメーターに対応付ける方法については、README.md の モデルの選定 セクションを参照してください。

プロダクト戦略担当（リーダー）

• ユーザー価値：実際のユーザーの問題を解決できますか？市場に適合していますか？
• 優先度：今、これに取り組むべきでしょうか？
• 推奨事項：戦略上の考慮事項、ポジショニング

リーンデリバリーリーダー

• リーンなスコープ：フィードバックを得るためにリリースできる最小限のバージョンは何ですか？
• フィードバックを得るまでの速さ：どれだけ早くユーザーに提供できますか？
• 機能フラグ戦略：機能フラグを使ってプロトタイプを公開すべきでしょうか？
• 推奨事項：より迅速にリリースし、より早く学ぶ方法

デザインリーダー — ui-design に相談

• デザインの品質：ブランドとの一貫性はありますか？UX は直感的ですか？
• アクセシビリティ：WCAG への準拠要件はありますか？
• 推奨事項：デザインの進め方、必要なコンポーネント

ビジネスオペレーションリーダー

• コスト分析：必要な予算は？インフラコストは？
• ROI の見込み：投資収益率はどの程度見込めますか？
• 推奨事項：コスト最適化、または予算上の懸念

プリンシパルエンジニア — full-stack-orchestration に相談

• 技術的な実現可能性：構築可能ですか？複雑さのレベルは？
• アーキテクチャとの適合性：現在の技術スタックと整合していますか？
• 推奨事項：技術的な制約や代替アプローチ

フロントエンドスペシャリスト — frontend-mobile-development に相談

• 実装の評価：UX の実現可能性は？コンポーネントの複雑さは？
• ユーザーエクスペリエンス：実装上の課題はありますか？
• 推奨事項：フロントエンドの実装方針

すべての投票と推奨事項を含む、プロダクト評議会の評価全体を提示してください。

プロダクト評議会後の統合

評議会で投票が行われた後、結果をそのまま伝えるだけにしないでください。独自の分析を加えます。

• 評議会のどの意見に賛成しますか？ 最も有力な論点を補強します。
• どの意見に反対しますか？ 評議会メンバーの評価が的外れだと感じた場合は、その旨を伝え、理由を説明します。
• 評議会が見落とした点は何ですか？ 重要でありながら、誰も挙げなかった論点を特定します。
• 集団思考の確認：全員が賛成している場合は、あえて反対の立場を取ります。この機能に対する最も有力な反論は何ですか？
• 改善した提案：評議会の意見とステップ 2 で行った独自の批判的分析の両方を踏まえ、率直な提案を示します。提案どおりに構築する、スコープを変更する、延期する、または全面的に再検討する、のいずれかです。

チェックポイント：プロダクト評議会の結果と独自の統合分析をユーザーに提示します。評議会が指摘しなかった懸念があれば、ここで提起します。技術計画に進む前に、スコープと優先度の承認を待ちます。

ステップ 4：最小限のスコープを定義する

プロダクト評議会のフィードバックに基づき、以下を明確に定義します。

• MVP のスコープ：最初の段階（最長 1～2 週間）でリリースするものです。ユーザー向けの具体的な機能を列挙します。
• 今後のイテレーション：MVP の検証後に追加するものです。延期する機能を列挙します。
• 機能フラグの方針：フラグを使ってリリースするかどうかと、フラグ名を指定します。
• 成功指標：この機能がうまく機能していると判断する方法です。測定可能な成果を 2～3 個定義します。

ステップ 5：機能評議会を招集する

.claude/councils/feature-council.md から機能評議会のテンプレートを読み込み、技術的な実装計画を作成します。

モデルの選択：エージェントのモデル仕様と Task ツールのパラメーターの対応付けについては、README.md の モデルの選択 セクションを参照してください。

プリンシパルエンジニア（リード）— 相談先：full-stack-orchestration

• アーキテクチャとの適合性：システム設計と整合していますか？
• 複雑さの評価：スコープは適切ですか？
• 推奨事項：アーキテクチャ上の考慮事項、従うべきパターン

フロントエンドスペシャリスト — 相談先：frontend-mobile-development

• UI/UX のアプローチ：コンポーネント構成、ユーザー操作のフロー
• デザインとの統合：Tailwind/shadcn のコンポーネントが必要ですか？新規または既存のどちらですか？
• 推奨事項：フロントエンドの実装戦略

バックエンドスペシャリスト — 相談先：backend-development

• API 設計：エンドポイント、契約、データフロー
• データベースの変更：スキーマの変更が必要ですか？
• 推奨事項：バックエンドの実装戦略

機能に API の作業が含まれる場合は、詳細な API 設計のガイダンスとして /backend-development:api-design-principles を呼び出します。

QA リード

• テスト戦略：ユニット、統合、E2E のアプローチ
• エッジケース：テストするシナリオ、境界条件
• 推奨事項：品質ゲートと受け入れ基準

実装計画

評議会の意見に基づき、構造化されたタスクの内訳を作成します。

フロントエンドのタスク：コンポーネント開発、ルーティング、状態管理、スタイリング
バックエンドのタスク：API エンドポイント、サービス、ビジネスロジック、検証
データベースのタスク：スキーマの変更、マイグレーション、シードデータ
テストのタスク：テストの作成、カバレッジ目標、E2E シナリオ
推定複雑度：小／中／大

規模とスケジュールの見積もり：作成する各タスク／課題について、評議会は以下を提示する必要があります。

• 規模：XS（1 日）、S（2 日）、M（3 日）、L（5 日）、または XL（8 日）の営業日単位
• 依存関係：この課題を開始する前に完了している必要がある他の課題
• マイルストーン：課題が属するフェーズ（M1～M5）
• スケジュール上の順序：依存関係と既存のスケジュール済み項目を考慮した、マイルストーン内の直列キューにおける課題の位置

Feature Council 後の統合

Feature Council の投票後、独自の技術分析を追加します。

• 実装リスク：この計画で最も難しい部分は何ですか？チームが行き詰まったり、工数を過小評価したりする可能性が最も高いのはどこですか？
• 順序に関する懸念：タスクの分解と順序は適切ですか？フロントエンドとバックエンドの作業の間に、隠れた依存関係はありますか？
• 過剰な設計の確認：Council は、この機能に必要な範囲を超えるインフラを提案していますか？仮説を検証するために、もっと簡素な方法はありますか？
• 設計不足の確認：後で問題になりそうな見落としはありませんか？エラー処理、マイグレーションのロールバック、アクセシビリティ、パフォーマンスなどを確認します。
• 率直な評価：これまでの議論を踏まえて、この計画が記載どおりに成功する確信度を（High／Medium／Low）で評価し、その理由を説明します。

チェックポイント：Feature Council の実装計画と技術的な統合結果をユーザーに提示します。順序、リスク、スコープに関する懸念があれば明確に伝えます。続行する前に、タスクの分解について承認を待ちます。

ステップ 6：意思決定記録を作成する

docs/decisions/ にある既存ファイルを読み、次の決定番号を特定します。

テンプレート docs/decisions/001-example-architecture-decision.md を使用して、以下を含む意思決定記録を作成します。

• 日付：今日の日付
• Council：Product Council + Feature Council
• ステータス：承認済み（ユーザーの承認後）
• 質問：評価対象の機能
• コンテキスト：現状、要件、制約
• Council の投票：Product Council と Feature Council の全投票
• 決定：承認されたスコープ（MVP + 将来）
• 根拠の要約：すべての Council メンバーの見解を統合したもの
• アクション項目：担当者が明確なタスクの分解（フロントエンド、バックエンド、テスト）
• タイムライン：複雑さに基づく目標日
• フォローアップ：再検討する時期と、リリース後に検証する内容
• 参考資料：関連する issue、ドキュメント、過去の決定

GFM の書式要件

意思決定記録は GitHub Flavored Markdown で表示されます。.claude/CLAUDE.md の GFM ルールに従ってください。

• メタデータブロックでは箇条書き（- **キー**：値）を使用し、太字の行を連続させないでください。
• コールアウトには、太字や斜体の強調ではなく GitHub アラート（> [!NOTE]、> [!TIP]、> [!IMPORTANT]、> [!WARNING]、> [!CAUTION]）を使用してください。
• 複数のコンポーネント、サービス、またはデータフローが関わる決定には、mermaid 図を含めてください。図は「コンテキスト」または「根拠の要約」セクションに配置し、アーキテクチャを図示します。
• 議論の記録が投票内容だけで約150行を超える場合は、長い Council 評価に折りたたみ可能な <details> セクションを使用してください。
• 選択肢とトレードオフなど、構造化された比較には表を使用してください。

アーキテクチャ上の選択を含む決定の場合は、ADR の書式ガイダンスとして /documentation-generation:architecture-decision-records を呼び出してください。

チェックポイント：保存する前に、意思決定記録をユーザーに提示して最終確認を受けます。

ステップ 7：ブランチを作成して成果物を保存する

1. CONTRIBUTING.md の規約に従い、最新の origin/main からフィーチャーブランチを作成します。

   git fetch origin main
   git checkout -b feature/<feature-slug> origin/main
   

2. 意思決定記録を保存します。

   docs/decisions/NNN-<feature-slug>.md
   

3. 意思決定インデックスを更新します。

   ディレクトリ内のすべての意思決定ファイルをスキャンし、docs/decisions/INDEX.md の Decisions テーブルを再生成します。各ファイル（INDEX.md と 001-example-architecture-decision.md を除く）について、次の処理を行います。

   • 見出しを読み取り、意思決定番号とタイトルを抽出する
   • メタデータブロックを読み取り、Date、Council、Status を抽出する
   • 意思決定の Question セクションと Context セクションから、2～5 個の主要トピック（小文字、コンマ区切り）を導き出す

   テーブル全体を時系列の逆順（新しいものが先）で再構築します。INDEX.md のほかのセクション（導入、How to Use、Related Resources）は変更しないでください。

4. マスタードキュメントインデックスを更新します。

   docs/ に新しいドキュメント（意思決定記録を含む）が作成された場合は、docs/INDEX.md に反映されていることを確認します。意思決定記録は、すでにある decisions/INDEX.md の項目でカバーされるため、意思決定ごとの更新は不要です。ただし、decisions/ 以外の docs/ に新しいドキュメントファイル（新しい科学ドキュメントなど）が追加された場合は、docs/INDEX.md の適切なテーブルに行を追加します。

5. 次の内容でコミットします。

   docs(council): document feature plan for <feature-name>
   

6. プッシュする前に、新規または変更したすべてのファイルに Prettier を実行します。

   pnpm exec prettier --write <files>
   

   フォーマット修正をステージングし、別途コミットします。

   style: fix Prettier formatting in decision record and skill
   

7. ブランチをプッシュし、意思決定記録の PR を作成します。

   git push -u origin feature/<feature-slug>
   
   gh pr create \
     --title "docs(council): add Decision NNN — <feature-name>" \
     --body "## Summary\n\n- Adds Decision NNN documenting the council-approved plan for <feature-name>\n- Product Council (<tally>) and Feature Council (<tally>) both approved\n- Implementation issues: #N, #N, ...\n\n## Test plan\n\n- [ ] Decision record renders correctly in GitHub markdown\n- [ ] Mermaid diagrams render (if any)\n- [ ] All cross-references to existing issues and docs are valid links\n\n🤖 Generated with [Claude Code](https://claude.com/claude-code)"
   

8. すべてのチェックに合格するまで CI を監視します。

   gh pr checks <pr-number> --watch
   

   チェックに失敗した場合は、失敗ログを読み、問題を修正してコミットし、プッシュして、再度監視します。CI が成功するまで、Issue の作成に進まないでください。

   重要

   意思決定記録を作成するすべての /plan-feature 実行では、その記録を main にマージするための PR を提出する必要があります。計画ステップを完了とみなすには、PR が CI に合格しなければなりません。意思決定記録のブランチは、/build-feature が実装に使用するフィーチャーブランチでもあります。

ソース GitHub Issue を更新する

計画が GitHub Issue（ステップ 1 で追跡）から開始された場合は、評議会の調査結果をソース Issue に反映します。これにより、計画の結果を反映した生きたドキュメントとして Issue を維持できます。

評議会の結果を要約したコメントをソース Issue に追加します。

gh issue comment <number> --body "$(cat <<'EOF'
## Council Planning Complete

### Product Council — <Vote tally> (Approve-Concern-Block)
<2-3 sentence summary of key Product Council decisions>

### Feature Council — <Vote tally> (Approve-Concern-Block)
<2-3 sentence summary of key technical decisions>

### Key Decisions
- <Decision 1>
- <Decision 2>
- <Decision 3>

### Artifacts
- **Decision Record**: [Decision NNN](docs/decisions/NNN-slug.md) _(link becomes active after the planning PR merges to main)_
- **Feature Branch**: `feature/<slug>`
- **Implementation Issue**: #<new-issue-number> (created in Step 9)

Planning completed via `/plan-feature`.
EOF
)"

ソース Issue に build-ready ラベルを追加します（計画が完了した状態です）。

gh label list | grep -q "build-ready" || gh label create "build-ready" --description "Planned by /plan-feature and ready for /build-feature" --color "0E8A16"
gh issue edit <number> --add-label "build-ready"

ソース Issue がプロジェクトボードにあることを確認する

ソース Issue にラベルを付けたら、Product Roadmap プロジェクトボードで追跡されていることを確認します。build-ready が付いていてもボードにない Issue は、/build-feature の自動選択で検出できない孤立した作業項目になります。

# Check if the issue is already on the project board
# --limit 200 covers the current board size; increase if the project grows beyond 200 items
EXISTING=$(gh project item-list {PROJECT_NUMBER} --owner {OWNER} --format json --limit 200 \
  | python3 -c "
import json, sys
data = json.load(sys.stdin)
for item in data.get('items', []):
    # <number> must be an integer literal, e.g., == 42, not == '42'
    if item.get('content', {}).get('number') == <number>:
        print(item['id'])
        break
")

# If not on the board, add it and set fields
if [ -z "$EXISTING" ]; then
  ITEM_ID=$(gh project item-add {PROJECT_NUMBER} --owner {OWNER} --url "https://github.com/{OWNER}/{REPO}/issues/<number>" --format json | python3 -c "import json,sys; print(json.load(sys.stdin)['id'])")
  # Set phase and milestone fields to match the implementation issues that will be created in the Issue Creation step
  gh project item-edit --project-id {PROJECT_ID} --id "$ITEM_ID" --field-id {PHASE_FIELD_ID} --single-select-option-id <phase-option-id>
  echo "Added issue #<number> to the project board and set phase."
fi

メモ

ソース Issue は、コンテキストとして元の内容を保持します。コメントには、各評議会の決定事項が明確な監査証跡として記録され、詳細な意思決定記録へのリンクも含まれます。Issue 作成ステップ（ステップ 9）で実装 Issue を作成した後、このコメントに実装 Issue 番号を追加するよう編集してください。

ステップ 8：Issue 作成前の検証

GitHub Issue を作成する前に、計画成果物を検証します。

1. 意思決定記録の完全性：意思決定記録ファイルが存在し、必須セクション（Question、Context、Council Votes、Decision、Rationale Summary、Action Items、Timeline）がすべて含まれていることを確認します。セクションが不足している場合は、作業を中断し、次に進む前に追加してください。

2. 評議会の合意：両方の評議会の投票セクションを確認し、「Block」票があるか調べます。「Block」票がある場合：

   警告

   評議会のメンバーがこの機能に「Block」票を投じています。未解決の「Block」票がある状態で実装 Issue を作成するのは通常ではありません。次に進む前に、懸念への対処を検討してください。

   作業を続行するか、先に懸念へ対処するかをユーザーに尋ねます。

3. タスクの内訳があること：Action Items セクションに少なくとも 1 つのタスク（チェックボックス行）が含まれていることを確認します。空の場合は作業を中断し、実装タスクを定義するようユーザーに尋ねます。

4. 承認状況：Decision セクションに Status: Approved と記載されていることを確認します。承認されていない場合は、次に進む前にユーザーに警告します。

5. 重複 Issue の検出：既存のオープン Issue を検索し、重複の可能性や大幅に重なる作業がないか確認します。

   gh issue list --state open --limit 200 --json number,title,labels
   

   計画中の Issue のタイトルと範囲を既存の Issue と比較します。重複の可能性が見つかった場合：

   警告

   重複の可能性があります：Issue #N のタイトル／範囲が類似しています。新しい Issue を作成する前に、既存の Issue を確認してください。

   重複の可能性がある Issue をユーザーに提示し、次のいずれにするか尋ねます。

   • (a) 代わりに既存の Issue を更新する（計画の背景をコメントとして追加する）
   • (b) それでも新しい Issue を作成する（範囲が実際に異なる場合 — その理由を説明する）
   • (c) 重複を避けるよう計画を調整する

   既存の作業項目と大幅に重複する Issue を作成してはいけません。

ステップ 9：GitHub Issue の作成

重要

GitHub Issue は意思決定記録から導き出される実行可能な作業項目であり、意思決定記録の代わりにはなりません。意思決定記録（ステップ 6）は、評議会による評価、根拠、アーキテクチャ上の背景を記録するプロジェクトレベルの正式な記録です。Issue は意思決定記録を参照し、/build-feature が利用するタスク中心のビューを提供します。

/build-feature を Issue からいつでも、すぐにでも数日後にでも実行できるよう、実装計画全体を含む GitHub Issue を作成します。

ラベルが存在することを確認する

gh label list | grep -q "feature-implementation" || gh label create "feature-implementation" --description "Implementation plan from /plan-feature" --color "1D76DB"
gh label list | grep -q "security-audit" || gh label create "security-audit" --description "Phase security audit checkpoint" --color "D93F0B"

Issue 本文をまとめる

.github/ISSUE_TEMPLATE/feature-implementation.yml のテンプレートに従って Issue 本文を作成します。次のセクションを含めます。

Problem Statement：意思決定記録の Question セクションと Context セクションを基にします。解決する課題と、その理由を説明します。

Council Decisions：両方の評議会について要約します。

• Product Council の投票結果と主な決定事項
• Feature Council の投票結果とアーキテクチャ上の決定事項
• 異論や条件があれば、その内容

評議会の投票全体が約 30 行を超える場合は、折りたたみ可能な <details> セクションを使用します。

Implementation Plan：意思決定記録の Action Items を、レイヤー（Frontend、Backend、Database、Testing）ごとにチェックボックス付きで整理します。これは /build-feature が利用する主要な内容です。

Success Metrics：リーンスコープの定義（ステップ 4）で示された測定可能な成果です。

Technical Context：アーキテクチャパターン、API コントラクト、スキーマ変更、コンポーネント構成など、主要な技術的決定事項です。

Decision Record Reference：意思決定記録ファイルへのリンクです：[Decision NNN](docs/decisions/NNN-slug.md)

Feature Branch：ステップ 7 で作成したブランチ名です。

Feature Flag：該当する場合は、フラグ名と戦略です。

Estimated Complexity：Feature Council による評価に基づく Small／Medium／Large です。

複数のIssueを作成する場合

実装計画に複数の独立したフェーズがある場合は、ユーザーに次のように尋ねます。

実装計画にはN個のフェーズがあります。次のどちらにしますか？

1. すべてのフェーズをタスクグループとして含む単一のIssue
2. フェーズごとに個別のIssue（相互に参照）

個別のIssueを作成する場合は、「Part X of N」と兄弟Issueへのリンクを含め、順番に作成します。各Issueは、正しいプロジェクトフェーズに割り当てる必要があります（下記の「フェーズとプロジェクトのマッピング」を参照）。

複数のフェーズのIssueを作成する場合は、親Issueも作成し、AGENTS.mdの「親IssueとサブIssue」セクションに従ってサブIssueの関係を設定します。

1. まず親Issueを作成します（機能の概要を記述し、実装の詳細は含めません）。
2. 各フェーズの子Issueを作成します。
3. サブIssue APIを使って、子Issueを親Issueにリンクします。

   CHILD_ID=$(gh api repos/{OWNER}/{REPO}/issues/<child-number> --jq '.id')
   gh api repos/{OWNER}/{REPO}/issues/<parent-number>/sub_issues -X POST -F sub_issue_id=$CHILD_ID
   

4. 親Issueの日付を、すべての子Issueの期間に合わせます（最も早い開始日から最も遅い目標日まで）。
5. 子Issueが複数のマイルストーンにまたがる場合：親Issueをマイルストーンから削除し（gh api repos/{OWNER}/{REPO}/issues/<number> -X PATCH -F milestone=null）、GraphQLのclearProjectV2ItemFieldValueでプロジェクトのフェーズフィールドをクリアします。親Issueは進捗管理用のコンテナです。マイルストーンとフェーズの割り当ては子Issueに設定します。元のIssueを親Issueとして使用し、すでにマイルストーンが設定されている場合は、そのマイルストーンを削除します。

フェーズとプロジェクトのマッピング

Issueの確認をユーザーに求める前に、各Issueに適切なプロジェクトフェーズとサイズを決定します。

1. {PROJECT_BOARD_NAME}の既存フェーズを確認します。

   gh project field-list 6 --owner {OWNER} --format json
   

2. docs/PRODUCT.mdのマイルストーンの内訳と作業の性質に基づいて、各Issueをフェーズに割り当てます。既存のロードマップの進行状況におけるIssueの位置付けを考慮します。

3. 計画中の作業が既存のフェーズに当てはまらない場合は、新しいフェーズを提案します。新しいフェーズの提案には、理由と既存フェーズに対する位置付け（例：「M2とM3の間」）を含める必要があります。

チェックポイント：ユーザーの確認のため、Issueの計画全体を提示します。

作成または変更するすべてのIssue、そのプロジェクトフェーズの割り当て、およびプロジェクトへの変更をまとめた表を提示します。

作成／更新するIssue：

操作	Issue	タイトル	フェーズ	サイズ	マイルストーン	開始日	目標日
作成	NEW	<title>	<phase>	<XS/S/M/L/XL>	<M1-M5>	YYYY-MM-DD	YYYY-MM-DD
更新	#N	<title>	<phase>	<size>	<M1-M5>	YYYY-MM-DD	YYYY-MM-DD

新しいフェーズを提案する場合：

新しいフェーズ	位置	理由
M_N_: <Name>	M_N_の後	このフェーズが必要な理由

対象フェーズにGTMレビューIssueまたはセキュリティ監査Issueを作成または更新する必要がある場合は（下記の「GTMレビューチェックポイント」と「セキュリティ監査チェックポイント」を参照）、概要に含めます。

Issueの作成またはプロジェクトの変更を行う前に、ユーザーから明示的な承認を得てください。

Issueの作成とプロジェクトへの割り当て

必要なラベルが存在することを確認します。

gh label list | grep -q "feature-implementation" || gh label create "feature-implementation" --description "Implementation plan from /plan-feature" --color "1D76DB"
gh label list | grep -q "build-ready" || gh label create "build-ready" --description "Planned by /plan-feature and ready for /build-feature" --color "0E8A16"
gh label list | grep -q "gtm-review" || gh label create "gtm-review" --description "Go to Market & Business Review checkpoint" --color "0E8A16"
gh label list | grep -q "security-audit" || gh label create "security-audit" --description "Phase security audit checkpoint" --color "D93F0B"

選択的な build-ready ラベル付け

作成する各イシューについて、/build-feature にそのまま進められるほど十分に計画されているかを判断します。

• イシューに build-ready を追加する：具体的なタスクの内訳、明確な受け入れ条件があり、重要な未解決事項がない場合です。単一イシューの計画や、複数イシューの計画における適切に範囲が定められた子イシューでは、これが一般的です。
• build-ready を追加しない：イシューの範囲が広い、アーキテクチャに関する未解決の疑問がある、または範囲を調整して評議会から意見を得るために、独自の /plan-feature の工程が望ましい場合です。これは、ハイレベルな方針だけが確立されている複数イシューの計画における、大規模な子イシューでよく見られます。

承認した各イシューを作成し、正しいフェーズ、サイズ、マイルストーン、日付を設定してプロジェクトに割り当てます。

# Create the issue (add --label "build-ready" if the issue is fully planned)
ISSUE_URL=$(gh issue create \
  --title "<title>" \
  --body "<body>" \
  --label "enhancement" \
  --label "feature-implementation" \
  --milestone "<milestone-name>" | tail -1)

# Extract issue number from URL
ISSUE_NUM=$(echo "$ISSUE_URL" | grep -o '[0-9]*$')

# Add to project and set phase + size fields
ITEM_ID=$(gh project item-add {PROJECT_NUMBER} --owner {OWNER} --url "$ISSUE_URL" --format json | python3 -c "import json,sys; print(json.load(sys.stdin)['id'])")
gh project item-edit --project-id {PROJECT_ID} --id "$ITEM_ID" --field-id {PHASE_FIELD_ID} --single-select-option-id <phase-option-id>
gh project item-edit --project-id {PROJECT_ID} --id "$ITEM_ID" --field-id {SIZE_FIELD_ID} --single-select-option-id <size-option-id>

# Set Start and Target dates (computed from size estimate and schedule position)
gh project item-edit --project-id {PROJECT_ID} --id "$ITEM_ID" --field-id {START_FIELD_ID} --date <start-date>
gh project item-edit --project-id {PROJECT_ID} --id "$ITEM_ID" --field-id {TARGET_FIELD_ID} --date <target-date>

メモ

プロジェクトのフィールド ID — プロジェクトの構成が変更された場合は、gh project field-list 6 --owner {OWNER} --format json から最新情報を取得してください。

• Phase フィールド：{PHASE_FIELD_ID} — オプション：M0 (5d1aaeb2)、M1 (4cfa6c51)、M2 (27c0efa8)、M3 (ed327f33)、M4 (df98aad8)、M5 (0604582f)
• Size フィールド：{SIZE_FIELD_ID} — オプション：XS (88044618)、S (27e6800e)、M (c4753411)、L (cde643b6)、XL (286a9b9c)
• マイルストーン番号：M0=1、M1=2、M2=3、M3=4、M4=5、M5=6
• 開始日フィールド：{START_FIELD_ID}
• 目標日フィールド：{TARGET_FIELD_ID}

スケジュール日の計算

イシューを作成する際は、AGENTS.md のスケジュールルールに従って開始日と目標日を計算します。

1. 対象のマイルストーンで既存のスケジュールを確認します。

   gh project item-list {PROJECT_NUMBER} --owner {OWNER} --format json --limit 200
   

   マイルストーン内のゲート以外の項目について、最も遅い目標日を確認します。ゲート項目とは、gtm-review または security-audit のラベルが付いたイシューです。挿入位置を決める際は、これらを除外します。

2. 新しいイシューの日付を計算します。サイズと日数の対応表（XS=1、S=2、M=3、L=5、XL=8 営業日）を使用します。開始日は、マイルストーン内のゲート以外の項目の最も遅い目標日（または依存関係にあるイシューの目標日のうち、いずれか遅い方）の翌営業日です。週末は除外します。

3. 後続するすべての項目の日付を繰り下げます。新しいイシューを挿入した後、マイルストーン内でそのイシューに続くすべてのイシューの開始日と目標日を再計算します。各後続イシューの開始日は、直前のイシューの目標日の翌営業日です。連続するイシューの間に空白や重複があってはなりません。開始日と目標日によって作業の順序が決まります。

4. ゲート項目の日付を繰り下げます。各マイルストーンの最後には、必ず固定順序で2つのゲート項目を置きます。GTM review（最後から2番目）、次に security audit（最後）です。ゲート以外の項目の配置後、GTM review の開始日を最後のゲート以外の項目の目標日の翌営業日に、security audit の開始日を GTM review の目標日の翌営業日に再計算します。プロジェクトボードで両方のゲート項目の開始日と目標日を更新します。

5. security audit の新しい目標日がマイルストーンの期限を延長する場合は、期限を更新します。

   gh api repos/{OWNER}/{REPO}/milestones/<number> -X PATCH -f due_on="<new-target>T00:00:00Z"
   

   重要

   GTM review と security audit のゲート項目の後に、種類を問わず（機能、バグ修正、雑務、テストなど）イシューをスケジュールしてはなりません。この2つの項目は、各マイルストーンの常に最後の項目であり、その順序（GTM → security audit）は、すべてのプロジェクト更新で維持しなければならない不変条件です。

6. 開始日フィールド ID と目標日フィールド ID を使用して、影響を受けるすべての項目をプロジェクトボードで更新します。再計算するのは現在開発中のマイルストーンのみです。後続のマイルストーンは、現在のマイルストーンが終了した時点で調整します。

複数のイシューがリクエストされた場合は、それぞれを順に作成し、相互参照用にイシュー番号を記録します。

作成したイシュー番号、URL、プロジェクトのフェーズ割り当て、マイルストーン、スケジュール日を報告します。

GTM レビューチェックポイント

各プロジェクトフェーズの最後に、包括的な Go to Market & Business Review イシューを必ず設けてください。機能イシューを作成または割り当てた後、影響を受ける各フェーズについて、GTM の網羅性を確認してください。

1. 影響を受けるフェーズに既存の GTM レビューイシューがあるか確認します。

   gh issue list --state open --label "gtm-review" --json number,title
   

2. GTM レビューイシューがないフェーズについては、新しいイシューを作成します。

   gh issue create \
     --title "gtm: Go to Market & Business Review — <Phase Name>" \
     --body "<body>" \
     --label "enhancement" \
     --label "marketing" \
     --label "gtm-review"
   

   GTM レビューイシューの本文には、次の項目を含めてください。

   • フェーズ概要：このフェーズに含まれる機能と変更
   • マーケティングページの監査：ランディングページ、機能の説明、スクリーンショット、CTA に、このフェーズの変更が反映されているか確認するチェックリスト
   • コンテンツの一貫性：ブログ記事、ヘルプドキュメント、アプリ内の文言と新機能との整合性
   • GTM の推奨事項：ポジショニング、メッセージング、ローンチ施策、チャネル戦略
   • ビジネスレビュー：収益への影響、価格設定への影響、競合上のポジショニングの更新
   • 成功指標：このフェーズの GTM 効果の測定方法

   重要

   GTM 作業で作成するユーザー向けの文言（ランディングページ、ブログ記事、アプリ内テキスト、マーケティングコンテンツ）はすべて、AGENTS.md の ユーザー向けコンテンツのスタイルのルールに従う必要があります。エムダッシュ、AI らしい定型表現、誇大な宣伝表現は使用しないでください。

   正しいフェーズ、サイズ、マイルストーン、日付を設定して、GTM レビューイシューをプロジェクトに追加します。

   GTM_URL=<created-issue-url>
   GTM_NUM=$(echo "$GTM_URL" | grep -o '[0-9]*$')
   
   # Add to project and set fields
   GTM_ITEM_ID=$(gh project item-add {PROJECT_NUMBER} --owner {OWNER} --url "$GTM_URL" --format json | python3 -c "import json,sys; print(json.load(sys.stdin)['id'])")
   gh project item-edit --project-id {PROJECT_ID} --id "$GTM_ITEM_ID" --field-id {PHASE_FIELD_ID} --single-select-option-id <phase-option-id>
   gh project item-edit --project-id {PROJECT_ID} --id "$GTM_ITEM_ID" --field-id {SIZE_FIELD_ID} --single-select-option-id <size-option-id>
   gh project item-edit --project-id {PROJECT_ID} --id "$GTM_ITEM_ID" --field-id {START_FIELD_ID} --date <start-date>
   gh project item-edit --project-id {PROJECT_ID} --id "$GTM_ITEM_ID" --field-id {TARGET_FIELD_ID} --date <target-date>
   

   GTM イシューのサイズは S（2 営業日）です。開始日は、そのフェーズにおける最後の機能イシューの目標日の翌営業日とします。日付は、機能イシューと同じスケジュール算出ロジックを使って計算してください（上記のスケジュール日付の算出を参照）。

3. すでに GTM レビューイシューがあるフェーズについては、新たに計画された作業がレビューの対象に含まれているか確認します。フェーズの範囲が大幅に拡大した場合は、レビューが必要な新しい項目を既存の GTM イシューにコメントとして追加してください。

重要

GTM レビューイシューにより、リリース可能なすべてのフェーズにビジネスレビューのチェックポイントが設けられます。これは任意ではありません。フェーズが完了と見なされる前に、必ず各フェーズに設けてください。免除：バグ修正のみを行うフェーズ、または継続的なデリバリーやメンテナンスのみを行うフェーズ（依存関係のアップグレード、セキュリティパッチ、CI の改善など）は免除されます。

セキュリティ監査ゲート

プロジェクトの各フェーズは、最終作業項目として包括的なセキュリティ監査の Issue で締めくくる必要があります。これは、GTM レビュー中に導入されたコード変更も監査の対象にするためです。GTM の対象範囲を確認した後、影響を受けるすべてのフェーズについて、セキュリティ監査の対象範囲を確認します。

1. 影響を受けるフェーズに既存のセキュリティ監査 Issue があるか確認します。

   gh issue list --state open --label "security-audit" --json number,title
   

2. セキュリティ監査 Issue がないフェーズには、Issue を作成します。

   gh issue create \
     --title "security: Comprehensive Security Audit — <Phase Name>" \
     --body "<body>" \
     --label "enhancement" \
     --label "security-audit"
   

   セキュリティ監査 Issue の本文には、次の項目を含める必要があります。

   • フェーズの概要：セキュリティレビューが必要な、このフェーズに含まれる機能、サービス、変更
   • 監査範囲：影響を受けるコードベースの領域（API エンドポイント、認証フロー、データモデル、サードパーティ連携など）
   • SAST スキャン：フェーズ内のすべてのコード変更に対して、自動静的解析を実行する
   • STRIDE 脅威モデリング：新規または変更された機能に STRIDE 手法を適用する
   • 攻撃ツリー分析：脅威モデリングで特定した上位 3 件のリスクについて、攻撃ツリーを作成する
   • 依存関係の監査：新規または更新された依存関係に既知の脆弱性がないか確認する
   • 修正計画：重要度評価と修正の推奨事項を含む、優先順位付きの検出事項リスト

   正しいフェーズ、サイズ、マイルストーン、日付を設定して、セキュリティ監査 Issue をプロジェクトに追加します。

   SEC_URL=<created-issue-url>
   SEC_NUM=$(echo "$SEC_URL" | grep -o '[0-9]*$')
   
   # Add to project and set fields
   SEC_ITEM_ID=$(gh project item-add {PROJECT_NUMBER} --owner {OWNER} --url "$SEC_URL" --format json | python3 -c "import json,sys; print(json.load(sys.stdin)['id'])")
   gh project item-edit --project-id {PROJECT_ID} --id "$SEC_ITEM_ID" --field-id {PHASE_FIELD_ID} --single-select-option-id <phase-option-id>
   gh project item-edit --project-id {PROJECT_ID} --id "$SEC_ITEM_ID" --field-id {SIZE_FIELD_ID} --single-select-option-id <size-option-id>
   gh project item-edit --project-id {PROJECT_ID} --id "$SEC_ITEM_ID" --field-id {START_FIELD_ID} --date <start-date>
   gh project item-edit --project-id {PROJECT_ID} --id "$SEC_ITEM_ID" --field-id {TARGET_FIELD_ID} --date <target-date>
   

   セキュリティ監査 Issue のサイズは M（3 営業日）です。開始日は、同じフェーズにある GTM Issue の目標日の翌営業日です。セキュリティ監査は、常にフェーズの最後の Issue です。日付は、機能 Issue と同じスケジュール計算ロジックを使って算出します（上記の「スケジュール日付の計算」を参照）。

3. すでにセキュリティ監査 Issue があるフェーズでは、新たに計画された作業が監査の対象になっているか確認します。フェーズの範囲が大幅に拡大した場合は、レビューが必要な新しい項目を記載したコメントを既存のセキュリティ監査 Issue に追加します。

重要

セキュリティ監査 Issue により、リリース前にリリース可能な各フェーズでセキュリティチェックポイントを確実に実施できます。これは任意ではなく、フェーズを完了と見なす前に、すべてのフェーズで実施する必要があります。セキュリティ監査は常にフェーズの最後の Issue として、GTM レビューの後に実施します。/security-audit を使って実行してください。免除：純粋なバグ修正、または継続的なデリバリー／メンテナンス（依存関係のアップグレード、セキュリティパッチ、CI の改善など）のみを行うフェーズは免除されます。GTM レビューと同じ扱いです。

ステップ 10：概要を出力する

明確な概要を提示します。

• 承認済みの範囲：MVP の機能と、後回しにする項目
• タスクの内訳：フロントエンド、バックエンド、データベース、テストのタスク
• 機能フラグ：名前と戦略（該当する場合）
• 成功指標：成果の測定方法
• ブランチ：実装準備が整った機能ブランチ名
• 意思決定記録：参照用のファイルパス
• GitHub Issue：実装計画の Issue 番号と URL
• プロジェクトフェーズ：各 Issue が割り当てられている製品ロードマップ上のフェーズ
• GTM の対象範囲：影響を受けるフェーズの GTM レビュー Issue — 作成、更新、または確認済み
• セキュリティ監査の対象範囲：影響を受けるフェーズのセキュリティ監査 Issue — 作成、更新、または確認済み

次のステップ：フルスタック実装には /build-feature <issue-number> を、バックエンドのみの作業には /build-api を実行します。