메뉴
When something goes wrong during a build, diagnose what type of failure it is before deciding how to respond. Targeted fix, hard reset, or full rethink — the right response depends on the right diagnosis.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | recover |
| description | When something goes wrong during a build, diagnose what type of failure it is before deciding how to respond. Targeted fix, hard reset, or full rethink — the right response depends on the right diagnosis. |
Not every problem is a bug. Not every bug needs debugging.
When something goes wrong with AI-assisted development, the instinct is to keep prompting — describe the problem, ask for a fix, get another broken version, describe that problem, ask for another fix. The session gets longer. The context gets polluted. The code gets worse.
The problem is not the code. The problem is not knowing what type of failure you are dealing with.
This skill diagnoses the failure first. Then it prescribes the right response. Those are two separate steps and they cannot be swapped.
The developer describes the problem. The skill listens before doing anything else.
Ask:
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?
Read the answer carefully. The number of fix attempts is important — it tells you whether this is a fresh problem or a session that has already gone wrong.
Based on the description, determine which of three failure modes this is.
Signs:
What it means: This is a normal bug. It has a root cause that can be found and fixed precisely.
Response: Targeted fix — go to Step 3A.
Signs:
What it means: The session is polluted. More prompting will not help — it will compound the damage. The feature needs to be rebuilt in a clean context, not patched further.
Response: Hard reset — go to Step 3B.
Signs:
What it means: This is not a debugging problem. The approach needs to be reconsidered before any code is written. More implementation in the wrong direction makes things harder to untangle.
Response: Rethink — go to Step 3C.
Tell the developer which failure mode this is before proceeding:
This looks like Failure Mode [1/2/3] — [name].
[One sentence explaining why you identified it this way.]
Here is how we handle this:
For Failure Mode 1.
Ask the developer to share:
Read the relevant code. Do not read the entire codebase — only what is directly relevant to the problem.
Identify the root cause before suggesting any fix. A root cause is the actual reason the problem exists — not a symptom of it.
State the root cause clearly:
Root cause: [specific explanation of why this is happening]
This is different from the symptom because: [explanation]
Describe the fix that addresses the root cause. Not a workaround. Not a patch on top of broken code.
Fix: [what needs to change and why]
This will resolve the root cause because: [explanation]
Wait for the developer to confirm before making any changes.
If the suggested fix does not resolve the problem — stop. Do not suggest another fix immediately.
Re-examine the root cause diagnosis. If the fix did not work, the root cause was probably wrong. Diagnose again from the beginning before trying again.
If two root cause diagnoses have both been wrong — this may actually be Failure Mode 2 or 3. Re-evaluate.
For Failure Mode 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.
Before the session ends, extract anything valuable from the current state:
Write this as a brief reset note:
## 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.
For Failure Mode 3.
The foundation being wrong means something was assumed that should not have been. Find it.
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.
Based on the correct understanding, describe what the approach should have been:
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]
A rethink needs the developer to understand and agree before any code changes. Present the analysis and wait for confirmation.
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.
Only after the developer confirms does any rebuilding begin.
The worst thing you can do when something is broken is keep doing the same thing faster.
Diagnose first. Respond correctly. Different failures need different responses — and knowing which failure you are dealing with is more than half the solution.
Save what matters at the end of a session so the next session picks up exactly where you left off. Or restore context at the start of a new session so nothing is lost between them.
Think through what you are about to build like a senior engineer before writing any code. Surfaces decisions, aligns on language, and produces a clear implementation plan you confirm before anything starts.
After building any UI component, extract the visual patterns that matter for consistency and save them to ui-registry.md. So every component built after this one matches what came before.
After building a feature, verify it matches what was planned, respects the system architecture and design standards, and is ready for production. Reports issues clearly so the developer decides what to fix.