start-requirements

name	start-requirements
description	要件定義書を作成する。3モード対応: 対話形式でゼロから/既存コード解析で逆算/Figma デザインから抽出。 完了後にレビュー+自動修正→ToC更新→commit の完了フローを実行する。 トリガー: "要件定義", "要件定義書作成", "ソースから要件抽出", "Figma から要件"
user-invocable	true
argument-hint	[feature-name] [--mode interactive|reverse-engineering|from-figma] [--new|--add]

/forge:start-requirements

要件定義書を作成する。3つのモードに対応:

• interactive: ゼロから対話しながら要件を固める
• reverse-engineering: 既存アプリのソースコードから要件を抽出
• from-figma: Figma デザインファイルから要件とデザイントークンを作成

Goal

選択モード（interactive / reverse-engineering / from-figma）に応じて要件定義書を作成し、レビュー+自動修正・ToC更新・commit まで完走すること。

フロー継続 [MANDATORY]

Phase 完了後は立ち止まらず次の Phase に自動で進む。不明点がある場合のみ AskUserQuestion で確認する。

議論モードの基本原則 [MANDATORY]

ユーザーの「叩き台を作って」「全面改訂してレビューしよう」「議論しよう」「壁打ち」は 議論起点 であり、決定フローではない。詳細は requirements_interactive_workflow.md § 対話の基本原則 8-11 を参照。

要点のみ:

• 叩き台を書いたら一度止まる。連続 AskUserQuestion で詰めない
• 改訂履歴セクションを作らない (履歴は CHANGELOG.md、設計判断の変更は ADR へ)
• 大規模 rewrite 後は grep で stale 文言を必ず検査
• システム的 feature は「用語 → アーキテクチャ → 状態 → データモデル → 要件」の順で積み上げる
• 「批判的にレビュー」依頼には A/B/C 比較 + 1 推奨案 + 決定は委ねる、のフォーマットで返す

コマンド構文

/forge:start-requirements [feature] [--mode interactive|reverse-engineering|from-figma] [--new|--add]

引数	内容
feature	Feature 名（省略時は対話で確定）
--mode	モード指定（省略時は選択肢提示）
--new	新規アプリ
--add	既存アプリへの機能追加

---

前提確認 [MANDATORY]

Step 1: モード選択

--mode 未指定時、AskUserQuestion を使用して選択肢を提示する:

どの方法で要件定義を開始しますか？
1. interactive         — ゼロから対話しながら要件を固める
2. reverse-engineering — 既存アプリのソースコードを解析して要件を抽出
3. from-figma          — Figma デザインファイルから要件とデザイントークンを作成

---

Phase 0: 事前確認（全モード共通）

フィーチャー概念の把握 [MANDATORY]: フラグ問わず以下を Read し、フィーチャーとは何か・名前空間の原則を把握する。

• ${CLAUDE_PLUGIN_ROOT}/docs/additive_development_spec.md §0 — フィーチャーの概念定義

1. 新規/追加の確認:

   • --new 指定 → 新規アプリとして処理
   • --add 指定 → 既存アプリへの機能追加として処理
   • 未指定 → AskUserQuestion を使用して確認する

   --add（追加開発）の場合 [MANDATORY]: 以下を Read し、判定基準・矛盾時の優先度・merge 手順を把握したうえで後続 Phase に進む。

   • ${CLAUDE_PLUGIN_ROOT}/docs/additive_development_spec.md §1 適用条件・対象外、§6 frontmatter 定義一覧
   • ${CLAUDE_PLUGIN_ROOT}/docs/requirement_format.md の「追加 feature 用 frontmatter」節 — type: temporary-feature-requirement 定義

2. Feature 名の確定:

   ${CLAUDE_PLUGIN_ROOT}/skills/doc-structure/SKILL.md の「出力先ディレクトリの解決」手順に従い、 doc_type requirement（feature 未指定）で既存ファイルの有無を確認し、以下の3分岐で確定する:

   • 引数で指定済み → 変更せずそのまま使用（AI による置き換え禁止）
   • 未指定かつ既存ファイルが存在しない（初回立ち上げ）→ フィーチャー名不要。同手順の対象ディレクトリに 直接配置する（additive_development_spec.md §0 参照）
   • 未指定かつ既存ファイルが存在する → AskUserQuestion でフィーチャー名を確認する

3. 出力先ディレクトリの解決:

   ${CLAUDE_PLUGIN_ROOT}/skills/doc-structure/SKILL.md の「出力先ディレクトリの解決」手順に従い、 doc_type requirement、feature {feature} で出力先ディレクトリを求める。

   • requirement に対応するエントリが無い場合 → specs/{feature}/requirements/ をデフォルトとして使用

---

ワークフローの実行 [MANDATORY]

モード確定後、該当するワークフローファイルを Read し、そのファイルの指示に従って作業を実行する。

モード	ファイルパス
interactive	${CLAUDE_PLUGIN_ROOT}/skills/start-requirements/docs/requirements_interactive_workflow.md
reverse-engineering	${CLAUDE_PLUGIN_ROOT}/skills/start-requirements/docs/requirements_reverse_engineering_workflow.md
from-figma	${CLAUDE_PLUGIN_ROOT}/skills/start-requirements/docs/requirements_from_figma_workflow.md

Read 後、ワークフローファイルの Phase 1 から開始する。各ワークフローは完了処理（AI レビュー・ToC 更新・commit 確認）まで自己完結している。SKILL.md に戻る必要はない。