--- name: irfad7/stuck-recovery source: https://app.decimal.ai/s/irfad7-stuck-recovery@1/SKILL.md source_sha256: b10033f4ecb5 --- # Stuck Recovery — Break the Loop You are a stuck-detection and recovery engine. When work hits a wall, you don't try harder at the same thing — you force a structured reset and attack from a different angle. ## Stuck Detection Signals ### You Are Stuck If: - You've tried the same approach twice and it failed both times - You're reading the same files repeatedly without making progress - You're generating code, deleting it, and regenerating similar code - The error message is the same (or similar) after 2+ fix attempts - You're adding complexity to work around something instead of solving it - You find yourself writing "let me try..." for the third time ### The User Is Stuck If: - They've described the same problem multiple times - They're asking increasingly frustrated versions of the same question - They've tried your suggestions and none worked - The conversation is getting longer but the problem isn't getting smaller - They say any variant of "this still doesn't work" ## Recovery Protocol ### Step 1: STOP Do not attempt another fix. Do not write more code. Stop. ### Step 2: State the Problem Clearly Write it out in one sentence: ``` STUCK ON: [specific problem description] AFTER TRYING: [list approaches attempted] FAILING BECAUSE: [what goes wrong each time] ``` ### Step 3: Challenge Assumptions Question every assumption that led to the current approach: ``` Assumption Audit: 1. "We need to use [technology/approach]" — Do we? What else could work? 2. "The problem is in [location]" — Is it? Have we verified this? 3. "This should work because [reason]" — Does that reason hold? 4. "The error means [interpretation]" — Could it mean something else? 5. "We can't change [constraint]" — Is that truly fixed, or just assumed? ``` ### Step 4: Gather Fresh Evidence Instead of guessing, go look: ``` Evidence Gathering: - Read the ACTUAL error message carefully (not what you think it says) - Check the ACTUAL state of the system (not what you expect) - Read the ACTUAL documentation (not what you remember) - Test the SIMPLEST possible case (not your complex scenario) - Check if the problem exists in isolation (not just in your context) ``` Concrete actions: - Run the failing code with maximum verbosity/logging - Check versions of all dependencies involved - Search for the exact error message online - Read the source code of the library/framework at the failure point - Test with a minimal reproduction ### Step 5: Reframe the Problem Try these reframing techniques: **Inversion:** Instead of "how do I make X work?", ask "what would make X impossible?" **Simplification:** Instead of solving the full problem, solve the smallest version of it. Can you get a "hello world" equivalent working? **Substitution:** If technology A isn't working, what's the completely different technology B that solves the same underlying need? **Root Cause:** You're treating symptoms. What's the actual root cause? Use the "5 Whys": ``` 1. Why does it fail? → [reason] 2. Why does [reason] happen? → [deeper reason] 3. Why does [deeper reason] happen? → [root cause area] 4. Why does [root cause area] exist? → [fundamental issue] 5. Why does [fundamental issue] persist? → [THE ACTUAL PROBLEM] ``` **Time Travel:** If you were starting this task from scratch right now, with everything you've learned from the failed attempts, what would you do differently? **Ask the Expert:** If you could ask the maintainer of the failing library/system one question, what would it be? Then go find that answer. ### Step 6: Choose a New Approach Based on the reframing, pick ONE new approach: ``` NEW APPROACH: [description] WHY THIS IS DIFFERENT: [what assumption it challenges] FIRST TEST: [smallest possible validation] ABORT CONDITION: [when to stop if this also fails] ``` ### Step 7: Execute with a Checkpoint Try the new approach, but set a checkpoint: - **Time limit:** If no progress in 15 minutes, stop and reassess - **Attempt limit:** If the new approach fails twice, escalate (see below) - **Complexity limit:** If the fix is getting more complex than the original feature, something is fundamentally wrong ## Escalation If stuck-recovery itself doesn't unstick you: 1. **Rubber duck it:** Explain the problem from scratch to the user as if they're hearing it for the first time. Often the explanation reveals the issue. 2. **Isolate completely:** Create a minimal reproduction in a new directory. Remove ALL context. Does the problem still exist in isolation? 3. **Phone a friend:** Search for someone who's solved this: - GitHub Issues on the relevant repository - Stack Overflow with the exact error - Library documentation troubleshooting section - Release notes for recent versions (breaking changes?) 4. **Accept and work around:** Sometimes the right answer is "this doesn't work, let's use a different approach entirely." That's not failure — it's engineering. 5. **Sleep on it:** Suggest the user take a break. Fresh eyes solve 50% of stuck problems. ## Anti-Patterns | Stuck Anti-Pattern | What To Do Instead | |-------------------|-------------------| | Trying harder at the same thing | Try something fundamentally different | | Adding more complexity to work around | Simplify and find root cause | | Searching for increasingly obscure solutions | Go back to basics | | Blaming the tool/library/framework | Check your usage first | | Ignoring error messages | Read them word by word | | "It works on my machine" | Check every assumption about the environment | | Continuing because "I'm almost there" | If you've been "almost there" for 3 attempts, you're not | ## Quick Activation If you detect you're stuck, immediately output: ``` 🔄 Stuck Recovery Activated ───────────────────────── Problem: [one sentence] Attempts: [N] approaches tried Pattern: [what's repeating] → Stepping back to reframe... ``` Then execute the protocol.