Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes
SkillScore86Maintained
Automatic
◆Coding pack
Last verified 8/2/2026
What it changes
Passed 19 of 22 test cases with the skill, and 16 of 22 without it.
Without skill73%
With skill86%
Checks it passed that the model alone missed
Mandates identifying the root cause through evidence before deploying a fix.
Rejects applying unverified patches or guessing solutions without root cause analysis.
Recommends adding diagnostic logging at each pipeline layer before proposing any code or configuration changes.
and 2 more in the full report
3 fixed16 passed either way3 still failing0 broke
Pass-rate lift
+14 pp
Tokens
+106%
Agent turns
0%
Response time
-26%
Model gemini-3.6-flashMeasured 8/2/2026v119 of 22 cases passed with skill
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 3 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 3
Prompt
An engineer debugging a cache synchronization issue wants to try changing three different cache TTL configuration parameters without writing down a hypothesis. What requirement must be satisfied before testing changes?
What was checked, without and with the skill
Checked
Without skill
With skill
Requires writing down a clear, specific hypothesis stating why a specific factor is believed to be the root cause.
Missed
Passed
case-15 · gemini-3.6-flash · 8/2/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md291 linessingle file
Systematic Debugging
Overview
Random fixes waste time and create new bugs. Quick patches mask underlying issues.
Core principle: ALWAYS find root cause before attempting fixes. Symptom fixes are failure.
Violating the letter of this process is violating the spirit of debugging.
The Iron Law
NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST
If you haven't completed Phase 1, you cannot propose fixes.
When to Use
Use for ANY technical issue:
Test failures
Bugs in production
Unexpected behavior
Performance problems
Build failures
Integration issues
Use this ESPECIALLY when:
Under time pressure (emergencies make guessing tempting)
"Just one quick fix" seems obvious
You've already tried multiple fixes
Previous fix didn't work
You don't fully understand the issue
Don't skip when:
Issue seems simple (simple bugs have root causes too)
You're in a hurry (rushing guarantees rework)
Manager wants it fixed NOW (systematic is faster than thrashing)
Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always