build-first

Build-First — 高速イテレーション開発

詳細な計画を書く代わりに、WHY だけ固めて即実装し、動くものを見て判断する。

いつ使うか

このタスクは...
    │
    ├─ 正解がまだわからない（探索的）──► build-first ✅
    ├─ 見ないと判断できない（UI/UX）──► build-first ✅
    ├─ 小さく試して学びたい ──────────► build-first ✅
    │
    ├─ やるべきことが明確 ───────────► plan-first（従来の計画駆動）
    ├─ DB/API等の土台設計 ───────────► plan-first（間違えると高コスト）
    └─ バグ修正 ─────────────────────► investigate

判断に迷ったら build-first を選ぶ。 計画の無駄は見えにくいが、動くものからの学びは確実。

いつ使わないか

以下は「速く回す」と負債が膨らむ領域。plan-first を使う:

• データベーススキーマ設計
• 外部 API 契約の策定
• 認証・認可フロー
• 複数サービス間の連携設計

Workflow

Step 1: WHY を1文で固める

何を作るかではなく、なぜ作るかを1文で書く。

## WHY
[誰]が[何をできる/何が解決される]ようにする。

これが書けない場合、AskUserQuestion で確認する:

• 「これは誰のどんな問題を解決しますか？」
• 「これがないと何が困りますか？」

WHY が曖昧なまま実装に入ってはならない。 速く回すことと、目的なく作ることは違う。

Step 2: WHAT をスケッチする（5分以内）

実装の詳細は書かない。ユーザーの行動だけを箇条書きにする。

## WHAT（ユーザーが何をできるか）
- [ ] 〇〇を一覧で見られる
- [ ] △△を作成できる
- [ ] □□の結果が表示される

書いてはいけないもの:

• Widget Tree / コンポーネント構成
• ファイルパスやディレクトリ構造
• 具体的な UI レイアウト（spacing, color等）
• 技術的な実装手順

Step 3: 最小実装（Build）

WHAT の中から1つだけ選び、動くものを作る。

ルール:

• 1つの WHAT に集中する — 全部を一度に作らない
• 完璧を目指さない — ハードコード可、見た目は後、ロジック優先
• 判断に必要な最小限だけ作る — 「これで方向が正しいか判断できるか？」が基準
• 計画書を書かない — コードが計画の代わり

Step 4: 判断（Judge）

実装を見て、ユーザーに判断を仰ぐ。AskUserQuestion で:

動くものができました。確認をお願いします:

- [スクショ or 動作説明]

判断:
1. 方向は合っている → 次の WHAT に進む
2. 方向は合っているが調整が必要 → 具体的に何を変えるか教えてください
3. 方向が違う → WHY に立ち返って再検討

ユーザーのフィードバックなしに次に進まない。 自分だけで回すと「好みの迷路」に陥る。

Step 5: 反復（Iterate）

判断結果に応じて:

判断結果?
    │
    ├─ 方向OK → 次の WHAT を実装（Step 3 に戻る）
    │
    ├─ 調整が必要 → 変更点だけ修正して再度 Judge
    │
    ├─ 方向が違う → WHY は合っているか確認
    │     ├─ WHY は合っている → WHAT を書き直して Step 3
    │     └─ WHY も違う → Step 1 からやり直し
    │
    └─ 全 WHAT 完了 → Step 6 へ

Step 6: 固める（Solidify）

全ての WHAT が Judge を通過したら、初めてコードを整理する:

1. ハードコードを適切な設計に置き換え
2. テストを書く
3. リファクタリング（extract スキル等を活用）

探索フェーズのコードをそのまま本番にしない。 探索と整理は別のフェーズ。

アンチパターン

やりがちなこと	なぜダメか	代わりにやること
WHY を決めずに作り始める	何周しても収束しない	Step 1 を飛ばさない
全 WHAT を一度に作る	フィードバックが遅れる	1つずつ作って判断
ユーザー確認なしで次に進む	自分の思い込みで迷走	毎回 Judge を挟む
探索コードを磨き続ける	方向転換時に捨てにくくなる	雑に作って Judge、OKなら後で整理
土台（DB/API）も速く回す	手戻りコストが高すぎる	土台は plan-first

原則

• WHY だけは妥協しない — 1文で言えるまで実装に入らない
• 計画はコードで書く — ドキュメントではなく動くもので表現する
• 判断はユーザーに委ねる — AskUserQuestion で必ずフィードバックを得る
• 1つずつ作って回す — バッチサイズを最小にする
• 土台は別扱い — DB/API/認証は plan-first で慎重に

Integration

• investigate: 実装中にバグが出たら構造化デバッグに切り替え
• extract: Solidify フェーズでのファイル分割に使用
• local-code-review: Solidify 後のレビューに使用
• intent-first: WHY が曖昧な場合の深掘りに連携