Structured debugging methodology — use before proposing fixes for any error or failure. Covers: code bugs, build errors, deploy failures, config conflicts, dependency issues, infra problems. Also use when previous fix attempts failed or root cause is unclear.
SkillScore74Maintained
Automatic
◆Coding pack
Last verified 9/27/2026
What it changes
Passed 17 of 23 test cases with the skill, and 15 of 23 without it.
Without skill65%
With skill74%
Checks it passed that the model alone missed
The response mandates testing only one variable at a time.
The response prompts an architectural review with the team before proceeding.
The response requires formulating a single explicit hypothesis in cause-and-effect format.
and 3 more in the full report
4 fixed13 passed either way4 still failing2 broke
Pass-rate lift
+9 pp
Tokens
+63%
Agent turns
0%
Response time
-24%
Model gemini-3.6-flashMeasured 9/27/2026v117 of 23 cases passed with skill
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 4 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 4
Prompt
In our GraphQL service, the `getAuthor` query successfully resolves nested book data, but the `getPublisher` query throws a null pointer error when attempting to fetch nested book data. We are about to start guessing resolver modifications in `publisher_resolver.py`. What systematic phase step should be taken before forming hypotheses?
What was checked, without and with the skill
Checked
Without skill
With skill
The response directs comparing publisher_resolver.py against the working getAuthor implementation to pinpoint differences.
Missed
Passed
The response requires mapping structural differences between working and broken components before forming hypotheses.
Passed
Passed
case-09 · gemini-3.6-flash · 9/27/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md179 lines3 files
Systematic Debugging
Overview
Guessing fixes wastes time and creates new bugs. Quick patches hide root problems.
Core principle: Never fix before finding the root cause. Symptom fixing is failure.
Iron Law
Never propose a fix without root cause investigation.
Phase 0 or Phase 1 must be completed before any fix is proposed.
Phase 0 fixes are ONLY allowed when ALL of these are true:
External research found an official solution or known issue for this exact error
Change is single file, single point (config value, import, typo)
No logic changes
When to Use
All technical problems:
Test failures, build errors, deploy errors
Config conflicts, dependency issues
Infrastructure/environment problems
Unexpected behavior, performance issues
Especially when:
Under time pressure (urgency breeds guessing)
"Let me just quickly fix this" comes to mind
Multiple fix attempts have already been tried
Previous fixes didn't work
You don't fully understand the problem
The Phases
Each Phase must complete before proceeding to the next.
Apple's open-source `container` CLI to build, run, and manage OCI/Linux containers as
lightweight per-container VMs on Apple-silicon macOS — no Docker daemon required. Use when
the user mentions the `container` CLI, "apple container", running or building containers on
macOS without Docker/Podman, `container run`, `container build`, `container images`,
`container system start`, pushing/pulling images to a registry, or container networking on
macOS. This is Apple's `container` tool specifically (r