systematic-debugging
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
More from jssee/agents
slicing
Use when a chosen approach or clear build target needs to become ordered, demo-able slices. Natural follow-up to `shaping`, but also works from any clear description of what to build. Trigger on "break this down", "what's V1", "plan the rollout", "MVP then iterate", "ship incrementally", or work with multiple pieces that need sequencing.
10shaping
Use when working through a fuzzy idea before implementation. Always asks clarification questions first, then produces a requirements table, one or more viable shapes, a fit-check matrix, and a recommendation. Trigger on "not sure which approach", "should we build X or Y", "what's the scope", "tradeoffs", "before we start", or any request where multiple directions are possible.
10commit
Use when committing local changes while preserving clean, reviewable git history.
9simplify
Use when code has been recently written or modified and needs refinement for clarity, consistency, and maintainability before committing
3reducing-entropy
Use when evaluating designs, reviewing code, or refactoring - measures success by total code in the final codebase, not effort to get there. Bias toward deletion.
3write-skill
Create or revise SKILL.md instruction files that agents can follow reliably under context pressure.
3