「いきなり作らせる」のは失敗のもと。調査 → 計画 → 小さく実装 → 検証 → コミットのリズムが、品質とトークンの両方を守ります。
新規なら /init。既存なら技術スタック・ビルドコマンド・規約を簡潔に記載。この投資が以後の全セッションに効きます。
Shift+Tab で Plan モードへ。「ユーザー認証を追加したい。関連コードを調べて実装方針を提案して」と依頼すると、読み取り専用で探索し計画を提示します。
「DB は SQLite のままで」「テストは Vitest で」など計画段階で修正。VS Code ならプラン文書にインラインコメントを書けます。方向違いの実装をやり直すより、計画を直す方が圧倒的に安い。
1ファイル書いたらテスト、を繰り返すインクリメンタルが基本。脱線したら Esc で止めて軌道修正。
「この入力でこの出力」「スクリーンショットのこの見た目」など検証ターゲットを渡すと、Claude が自分でテストを回して自己修正。手戻り依頼が激減します。
「ここまでをコミットして」で、要約コミットメッセージ込みの git 操作まで実行。PR 作成も依頼できます。
| △ 曖昧 | ◎ 具体的 |
|---|---|
| このコードを改善して | auth.ts の login 関数に入力バリデーションを追加して。メール形式チェックと、パスワード8文字以上の検証 |
| バグを直して | カート画面で数量を0にすると合計が NaN になる。再現手順は…。期待値は行が削除されること |
曖昧な依頼はコードベース全体の走査を誘発し、トークンも時間も浪費します。対象ファイル・期待する挙動・制約条件を明示しましょう。さらに Fable 5 では「なぜそれが必要か」を添えると精度が上がります（→ 次章）。