よくある失敗パターン

Kitchen Sink セッション

1つのセッションで無関係なタスクを次々と処理すると、コンテキストが「何でも入り」状態になります。

# 悪い例
「認証を直して」
「ログページをデザインして」
「CI/CDを設定して」
「READMEを更新して」

# 良い例
「認証を直して」
→ 完了後、コミット
/clear
「ログページをデザインして」
→ 完了後、コミット

「それは違う」「こうして」と何度も修正を指示すると、コンテキストが汚染されます。

# 悪い例
「関数を作って」
→ 「違う、こうして」
→ 「まだ違う、これ」
→ 「そうじゃなくて...」

2回修正したら /clear

# 良い例
「関数を作って」
→ 「違う」
→ 「まだ違う」
/clear
「○○の要件で△△パターンを使って関数を作って」

より良いプロンプトを考えてから再開しましょう。

CLAUDE.md が長すぎると、重要なルールが埋もれます。

# 悪い例（300行以上の CLAUDE.md）
## 歴史
このプロジェクトは2020年に...

## 詳細な設計思想
...

## すべてのAPIの説明
...

# 良い例（簡潔な CLAUDE.md）
# コードスタイル
- TypeScript strict mode
- ESLint設定に従う

# コマンド
- テスト: npm test
- ビルド: npm run build

# 重要なルール
- PRは必ずレビューを通す

Claude の出力を検証せずに信頼してしまう。

# 悪い例
「機能を実装して」
→ コードが出力される
→ そのままコミット（テストなし）

# 良い例
「機能を実装して。テストも書いて」
→ コードとテストが出力される
→ 「テストを実行して」
→ テストがパス
→ コミット

常に検証手段を提供することが重要です。

スコープを指定せずに調査を依頼すると、Claude が延々と探索を続けます。

# 悪い例
「パフォーマンス問題を調査して」
→ Claude がすべてのファイルを読み始める
→ コンテキストが埋まる
→ 結論が出ない

# 良い例
「src/api/ 内でN+1クエリを探して」

スコープを明確に限定するか、サブエージェントを使いましょう。

Q1. Kitchen Sinkセッションの問題は？

Q2. 2回以上の修正指示後にすべきことは？

Q3. Trust-Then-Verifyギャップを防ぐには？