Step back and re-evaluate the current approach when it seems too complex, fragile, misaligned with the actual goal, or going in circles.
NewMaintained
Automatic
◆Coding pack
Last verified 8/3/2026
What it changes
Passed 7 of 22 test cases with the skill, and 8 of 22 without it.
Without skill36%
With skill32%
Checks it passed that the model alone missed
Must explicitly define the underlying goal as fetching user profile data once on mount
1 fixed6 passed either way13 still failing2 broke
Pass-rate lift
-5 pp
Tokens
+18%
Agent turns
0%
Response time
-27%
Model gemini-3.6-flashMeasured 8/3/2026v17 of 22 cases passed with skill
Tokens, turns and time describe resource use, not a dollar price.
See it in action
A test case the skill fixed. Same model, same prompt, with and without the skill.
Prompt
I've tried fixing this `useEffect` infinite loop in my React component three times by adding more `useRef` hooks and custom debounce functions, but it's still crashing the browser. The goal is just to fetch user profile data once when the component mounts. Review this situation and tell me what to do next.
What was checked, without and with the skill
Checked
Without skill
With skill
Must explicitly define the underlying goal as fetching user profile data once on mount
Missed
Passed
Must explicitly contrast the complexity of adding `useRef` and debounce against the simplicity of a standard data fetching approach
Passed
Passed
case-01 · gemini-3.6-flash · 8/3/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md61 linessingle file
Rethink or Reframe Skill
Purpose
Catch and correct situations where the current approach is wrong, overly complex, or unnecessary — before more time is spent building on a bad foundation.
When to Use
The plan or implementation is becoming much larger or more complex than the request justifies.
Repeated debugging/fixes aren't addressing the real problem.
A simpler, more direct solution becomes apparent mid-task.
The original request seems to solve a symptom rather than the actual user goal.
New information (from Understand the Project or during implementation) contradicts the original plan's assumptions.
When Not to Use
The current plan is working and appropriately scoped — don't second-guess it just to be thorough.
Minor friction that doesn't indicate a wrong direction (e.g. one extra file needed).
Required Inputs
The current plan or in-progress implementation.
The original request/goal.
Whatever triggered the doubt (error pattern, growing scope, new info).
Assumptions
Changing direction mid-task has a cost; only do it when the benefit is clear.
The user's underlying goal matters more than the literal original instruction if the two diverge.
Step-by-Step Workflow
Name the trigger: what specifically suggests the current approach is wrong or too complex? (e.g. "this requires touching 12 files for a small UI tweak", "three fixes haven't resolved the error", "there's an existing utility that already does this").
Restate the underlying goal in plain terms, separate from the specific approach taken so far.
Compare alternatives: is there a simpler, smaller, or more direct way to achieve the same goal?
Estimate the cost of switching: how much of the current work is reusable vs. wasted?
Decide:
If the simpler path is clearly better and switching cost is low/medium — switch, and briefly note why.
If the current path is still reasonable despite the friction — continue, noting the tradeoff.
If the decision is high-impact (significant rework, affects scope/timeline materially) — surface it to the user before switching.
If reframing the request itself (the literal ask doesn't serve the actual goal), explain the mismatch and propose the better-aligned approach — don't silently do something different from what was asked.
Rules and Best practices
Prefer the smallest change that correctly solves the actual problem.
Don't over-engineer: if a simple solution meets the requirement, don't build a general framework "just in case."
Don't under-engineer: if the simple path will clearly need to be redone soon, say so.