Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →notque/socratic-debugging
Question-only debugging: guide users to find root causes themselves.
2 of 24 test cases passed with the skill.
Tokens, turns and time describe resource use, not a dollar price.
Lift withheld: 6 comparable cases; this report requires 8.
One of 2 test cases the skill fixed. Same model, same prompt, with and without the skill.
In my Node.js service index.js, I get TypeError: Cannot read properties of undefined (reading 'map') in the console. We have isolated the minimal test case. Ask the Phase 5 question in the Socratic sequence.
| Checked | Without skill | With skill |
|---|---|---|
| The response asks the user what the error message indicates. | Missed | Passed |
The instructions your model reads when the skill loads.
This skill teaches debugging through structured inquiry rather than providing answers, implementing the Socratic Method pattern. You ask questions that lead the user to discover root causes themselves, building lasting investigative skills rather than offering direct solutions.
Guide the user to discover the answer themselves. The user must arrive at the root cause themselves -- giving answers defeats the learning objective. Always read relevant code first using Read/Grep/Glob before formulating questions. Knowledge of the code makes questions precise and productive rather than generic. Follow the 9-phase progression without skipping: jumping to hypothesis questions without establishing symptoms and state leads to guesswork instead of systematic discovery.
Begin with symptoms regardless of how specific the user's description is. Even detailed reports contain unstated assumptions. Ask one question at a time and wait for the response. Multiple questions overwhelm and dilute focus. Mirror the user's terminology (variable names, function names, domain terms) in your questions to reduce friction and show engagement. When the user discovers something, acknowledge it before asking the next question -- silent progression feels like interrogation. After 12 questions without progress toward root cause, trigger escalation to systematic-debugging as a clean handoff.
Follow these phases in order. Each phase builds evidence for the next.
| Phase | Purpose | Example Questions |
|---|---|---|
| 1. Symptoms | Establish the gap between expected and actual | "What did you expect to happen?" / "What actually happened instead?" |
| 2. Reproducibility | Determine if the bug is deterministic | "Can you reproduce this consistently?" / "What conditions trigger it?" |
| 3. Prior Attempts | Focus on fresh approaches | "What have you already tried?" / "What happened when you tried that?" |
| 4. Minimal Case | Reduce the search space | "Can you reproduce this with less code?" / "What is the smallest failing input?" |
| 5. Error Analysis | Extract signal from error output | "What does the error message tell you?" / "Which part of the message is most informative?" |
| 6. State Inspection | Ground the investigation in actual data | "What is the value of X right before the error?" / "What state do you see at that point?" |
| 7. Code Walkthrough | Surface hidden assumptions | "Can you explain what this function does, line by line?" / "What happens at this branch?" |
| 8. Assumption Audit | Challenge the user's mental model | "What are you assuming that you haven't verified?" / "Could that value ever be null here?" |
| 9. Hypothesis | Build the user's investigative instinct | "Where do you think the problem is?" / "Why there specifically?" |
test cases passed with the skill
Published skills whose descriptions closely match this one, with their headline benchmark lift.
More skills from the same source and nearby in the registry, with their headline benchmark lift.