kickoff

ゼロから始める新規プロジェクトで、ユーザーへのヒアリングをもとに .claude/docs/ のドキュメント一式を作成する。
既存リポジトリからの移植は /migrate を使う（そちらはコードからの逆生成）。

手順

Phase 1: ヒアリング

以下をユーザーに確認する。一度に全部聞かず、2〜3問ずつ対話で進める。

1. 一言で言うと？ — 「XXX に困っている YYY が、ZZZ するためのアプリ」の形で
2. 背景・課題 — なぜ作るのか、今どう困っているのか
3. 目的・ゴール — 何が達成できたら成功か（KPI があれば）
4. ターゲットユーザー — メインペルソナ（立場・規模・悩み・現在の解決手段）
5. ユーザー種別・権限 — 一般ユーザー / 管理者などの区分と、それぞれができること
6. コア機能 — v1.0 に必要な機能を列挙してもらう（優先度: 必須 / 重要 / 任意）
7. 収益モデル — 有料プランの有無、課金形態
8. 対象プラットフォーム — Web のみ / Mobile のみ / 両方
9. 競合・参考サービス — あれば

答えられない項目は飛ばしてよい。飛ばした項目は各ドキュメントに ⚠️ 要記入 と注記する（勝手に埋めて捏造しない）。

Phase 2: ドキュメント生成

ヒアリング結果をもとにテンプレートを埋める。

ドキュメント	埋め方
planning.md	ヒアリング結果をそのまま反映。用語集はコア機能から抽出したドメイン用語で初期化
spec.md	コア機能から画面一覧・データモデル・API の叩き台を起こす（関連機能列も記入）
roadmap.md	機能ステータス表にコア機能を転記し、フェーズ（基盤→BE→FE→結合）・前提機能を設定。全て「未着手」
CLAUDE.md	「プロダクトの目的（北極星）」に一言サマリと KPI を転記

spec.md の叩き台は推測を含むため、各セクション冒頭に <!-- 叩き台: ユーザーレビュー前 --> と注記する。

Phase 3: レビューと確定

1. 生成したドキュメントの要約（機能数・画面数・コレクション数・API 数）を提示する
2. 特に データモデルと権限設計 はユーザーと対話して確定する（後から変えるコストが最も高い）
3. 修正を反映したら注記を外し、確定とする

Phase 4: 次のアクション提案

確定後、/next を実行して最初のタスク（通常は「1_基盤」フェーズの認証・スキーマ）を提案する。

確認事項

• planning.md にヒアリング結果が反映されている（不明項目は ⚠️ 要記入）
• spec.md に画面・データモデル・API の叩き台がある
• roadmap.md の機能ステータス表が初期化されている
• CLAUDE.md の「プロダクトの目的（北極星）」が転記されている
• ユーザーがデータモデルと権限設計を確認した