調べる→計画する→作る→確かめる

Claude Code にいきなり「作って」と頼むと、目的とずれたものができる ことがあります。次の4段階で進めると、やり直しが減ります。

4つの段階

計画モードで始めます。起動時に指定するか、起動後に Shift + Tab で plan mode にします。

claude --permission-mode plan

src/auth の中を読んで、ログインとセッションの扱いを理解してください。
環境変数でパスワードなどを管理している方法も見てください。

計画モードでは、ファイルは変更されません。

Googleでのログインを追加したいです。どのファイルを変える必要がありますか?
流れも含めて、計画を作ってください。

出てきた計画を読み、おかしいところは直してもらいます。Ctrl + G を押すと、計画をエディタで直接編集できます。

計画に納得できたら、計画モードを抜けて(承認する、または Shift + Tab)、実装を頼みます。

計画のとおりに実装してください。実装したらテストを実行して、失敗したら直してください。

変更内容を確認して、わかりやすいメッセージでコミットしてください

変更が小さいとき(誤字の修正、変数名の変更など)は、計画を飛ばして、直接頼んでかまいません。「変更内容を1文で説明できる」なら、計画は不要です。

いちばん効果が大きいのは、Claude Code が自分で正しさを確認できる方法を渡す ことです。確認する方法があれば、Claude Code は「作る→確認→直す」を、自分で繰り返せます。

渡すもの	頼み方の例
テスト	「実装したら、テストを実行して、通るまで直して」
ビルド	「直したら `npm run build` を実行して、エラーが出ないことを確認して」
期待する結果	「`user@example.com` は有効、`user@.com` は無効になるようにして。例で確認して」
画面	「このデザインに近づけて。結果のスクリーンショットを撮って、違いを直して」

確認できない変更は、公開しないでください。Claude Code は、それらしく見えるコードを、エッジケース(まれな条件)を考えずに出すことがあります。テストや実行結果という証拠を見せてもらい、自分でも確認してください。

方針	悪い例	良い例
対象を絞る	「foo.py のテストを書いて」	「ログアウト中の場合を対象に、foo.py のテストを書いて」
見本を示す	「カレンダーを追加して」	「`HomeWidget` と同じ作りで、カレンダーを追加して」
症状を伝える	「ログインを直して」	「セッション切れのあと、ログインに失敗する。`src/auth/` のトークン更新を調べて、失敗するテストを書いてから直して」

作りたいものがまだぼんやりしているときは、Claude Code に質問してもらいます。

[作りたいもの]を作りたいです。細かい点を、私に質問してください。
画面、データの扱い、例外の場合、迷いそうな点を聞いてください。
聞き終えたら、仕様をSPEC.mdに書いてください。

仕様ができたら、/clear で会話をリセットして、SPEC.md を読ませて実装を始めます。