recover

すべての問題がバグとは限りません。すべてのバグでデバッグが必要なわけでもありません。

AI 支援開発で問題が起きると、ついプロンプトを送り続けてしまいがちです。問題を説明し、修正を依頼し、また壊れたバージョンを受け取り、その問題を説明して、また修正を依頼します。セッションは長引き、コンテキストは汚染され、コードは悪化します。

問題はコードではありません。問題は、どの種類の失敗に直面しているのか分からないことです。

このスキルでは、まず失敗を診断します。それから適切な対応を提案します。この2つは別々の手順であり、順序を入れ替えることはできません。

---

ステップ 1 — 何が問題だったかを説明する

開発者が問題を説明します。このスキルは、ほかのことをする前に話を聞きます。

次のように尋ねます。

Describe what is wrong. Be specific:
- What did you expect to happen?
- What happened instead?
- How many times have you tried to fix it already?

回答を注意深く読みます。修正を試みた回数は重要です。今回初めて起きた問題なのか、すでにうまくいかなくなっているセッションなのかを判断する手がかりになります。

---

ステップ 2 — 失敗モードを特定する

説明をもとに、3つの失敗モードのうちどれに当てはまるかを判断します。

失敗モード 1 — 特定の箇所が壊れている

兆候：

• 問題は限定的で、1つのコンポーネント、1つの関数、1つのルートに関するものです
• プロジェクトのほかの部分は正常に動作しています
• 修正を試みるのは1回目か2回目です
• エラーメッセージや誤った動作が明確で具体的です

意味： これは通常のバグです。根本原因を特定し、正確に修正できます。

対応： 対象を絞った修正 — ステップ 3A に進みます。

---

失敗モード 2 — セッションがうまくいかなくなっている

兆候：

• 複数回の修正で状況が悪化したり、新たな問題が発生したりしています
• コードが絡み合い、修正で別の修正を継ぎ当てています
• このセッションのコンテキストが失敗した試みでいっぱいです
• 元の問題が何だったのか、もはや明確ではありません

意味： セッションが汚染されています。さらにプロンプトを送っても解決せず、被害が広がるだけです。機能はこれ以上継ぎ当てるのではなく、クリーンなコンテキストで再構築する必要があります。

対応： 完全にリセット — ステップ 3B に進みます。

---

失敗モード 3 — 基盤が間違っている

兆候：

• コードは実行されますが、根本的に誤った動作をします
• Claude が、重要な要件、ライブラリ API、またはアーキテクチャパターンを誤解したまま、自信を持って構築を進めています
• 問題は実装上のバグではなく、実装そのものが間違っています
• アプローチが誤っているため、個々の箇所を修正しても解決しません

意味： これはデバッグの問題ではありません。コードを書く前に、アプローチを見直す必要があります。誤った方向で実装を続けると、後から問題を解きほぐすのがさらに難しくなります。

対応： 再考 — ステップ 3C に進みます。

---

先に進む前に、開発者に該当する失敗モードを伝えます。

This looks like Failure Mode [1/2/3] — [name].

[One sentence explaining why you identified it this way.]

Here is how we handle this:

---

ステップ 3A — 対象を絞った修正

失敗モード 1 の場合。

コードに触れる前に診断する

開発者に、次の情報を共有してもらいます。

• 正確なエラーメッセージ、または誤った動作
• 発生箇所の具体的なファイルまたは関数
• コードが本来行うべきことと、実際に行っていること

関連するコードを読みます。コードベース全体を読む必要はありません。問題に直接関係するものだけを読みます。

根本原因を特定する

修正を提案する前に、根本原因を特定します。根本原因とは、問題が存在する実際の理由であり、症状ではありません。

根本原因を明確に述べます。

Root cause: [specific explanation of why this is happening]

This is different from the symptom because: [explanation]

正確な修正を提案する

根本原因に対処する修正を説明します。回避策でも、壊れたコードへの継ぎ当てでもありません。

Fix: [what needs to change and why]

This will resolve the root cause because: [explanation]

変更を加える前に、開発者の確認を待ちます。

修正がうまくいかない場合

提案した修正で問題が解決しない場合は、いったん止めます。すぐに別の修正を提案してはいけません。

根本原因の診断を見直します。修正が効かなかったのであれば、根本原因の判断が誤っていた可能性があります。再度試す前に、最初から診断し直します。

根本原因の診断が2回とも誤っていた場合は、実際には失敗モード 2 または 3 かもしれません。改めて評価します。

---

ステップ 3B — 完全にリセットする

失敗モード 2 の場合。

状況を正直に認める

This session has gone too far in the wrong direction
to recover by patching. The right move is a clean start.

This is not a failure — it is the correct response
to a polluted context. A fresh session with clear intent
will be faster than continuing here.

残すべき価値のあるものを保存する

セッションが終わる前に、現在の状態から価値のある情報を抜き出します。

• 元の機能は、本来どのように動作する想定でしたか？
• 現在の実装のうち、実際に正しい部分はありますか？
• うまくいかないことについて、何がわかりましたか？
• 次のセッションで避けるべきことは何ですか？

簡潔なリセットメモとして記述します。

## Reset Note — [Feature Name]

### What we were building
[Original feature description]

### What went wrong
[Honest summary of how the session went off track]

### What to avoid next time
[Specific approaches or patterns that did not work]

### Starting point for next session
[Where to begin fresh — what to keep, what to discard]

開発者に指示する

Next steps:

1. Save this reset note somewhere accessible
2. End this session completely
3. Start a fresh session
4. Begin with /remember restore if memory exists
5. Approach [feature name] again with the reset note as context

Do not continue in this session.

---

ステップ 3C — 再考する

失敗モード 3 の場合です。

誤った前提を特定する

基盤が間違っているということは、前提にすべきでないことを前提としていたということです。その前提を見つけてください。

The core issue is not a bug — it is a wrong assumption:

Assumed: [what was assumed]
Reality: [what is actually true]

This means the current implementation cannot be fixed
by patching. The approach needs to change.

正しいアプローチを提案する

正しい理解に基づいて、どのようなアプローチを取るべきだったかを説明します。

Correct approach: [description]

Key difference from current approach: [explanation]

What needs to be discarded: [what cannot be salvaged]
What can be kept: [what is still valid]

すぐに再構築を始めない

再考するには、コードを変更する前に開発者が内容を理解し、同意する必要があります。分析を提示し、確認を待ちます。

Does this diagnosis match your understanding?

If yes — we can start fresh with the correct approach.
If no — tell me what I am getting wrong.

開発者が確認した後にのみ、再構築を始めます。

---

原則

何かが壊れたときに最悪なのは、同じことをより速く続けることです。

まず診断し、適切に対応します。失敗の種類によって必要な対応は異なります。どの失敗に直面しているかを把握することが、解決の半分以上を占めます。