brainstorming
brainstorming
You MUST use this before any creative work - creating features, building components, adding functionality, modifying behavior, or planning anything new, in software or out of it (a talk, a business, a renovation).
debugDiagnosis before prescription: reproduce, hypothesize, isolate, fix root cause, add a regression test; refactor mode maps deps, coupling and blast radius. Triggers: bug, error, fix, broken, not working, crashed, stack trace, exception, refactor, restructure, coupling, dependency map.
Independent GitHub snapshot · Automated classification · Original documentation governs
Diagnosis comes before prescription: a surgeon cutting before the X-ray is guessing with a
knife. Two modes, same discipline. bug (default) is the steps below. refactor swaps the
subject from a failure to a structure, and produces a plan instead of a fix.
Run agentdb recall with the exact error text, subsystem/library, failing
test, and known files/symbols. Recall again when the hypothesis changes or a new failure
appears; that is a new retrieval question. Reference on demand:
skills/debug/reference/debug-research.md.
HYPOTHESIZE: list 3 causes before pursuing any.
ISOLATE: binary search, O(log n) not O(n).
git bisect between known-good and known-bad commit. ~10 tests for 1000 commits.Diff working vs failing state (env, config, input, commit) before theorizing.
Flaky test: classify first as timing/race, shared state, unseeded randomness, or environment difference; only then propose a fix.
(gate: failure localized to a specific function/commit/input subset)
ROOT CAUSE: the error line is the FAILURE. The DEFECT is upstream.
FIX: root cause, not symptom.
<refactor_mode> Triggers: refactor, restructure, clean up, coupling, dependency, "what breaks if". Same rule: diagnose, then hand off. Do not start cutting inside this mode.
graphify affected <symbol> when the graph is fresh. Build the import/call map.scripts/complexity.sh.<diagnosis_output> When the run ends at a diagnosis rather than a fix, emit this and stop:
## Diagnosis: <title>
Mode: bug | refactor · Confidence: high | medium | low
Root cause: <one sentence naming the violated invariant>
Affected: <file - origin> | <file - downstream> ...
Blast radius: N files. Tier 1|2|3.
Hypotheses: 1. <h> -> CONFIRMED | REJECTED (<evidence>) ...
Recommended approach: <what, not how>
Tests required: <fails before> / <passes after>
Next: /kernel:ingest to implement, /kernel:simplify to restructure.
Decide and state the recommendation. Never stop to ask which hypothesis to pursue. </diagnosis_output>
<anti_patterns> Shotgun (random changes until it works) · fix-and-pray (never re-run the original case) · symptom fixing (null check at the crash site) · printf flooding (binary search first, then targeted logging) · blame-the-framework (it's almost never the library) · unscoped "investigate" (scope narrowly or use a subagent so the file reads don't fill context). </anti_patterns>
<when_stuck> Explain the problem in writing · re-read the error message (the answer is there most of the time) · reduce to a minimal reproduction · ask "what changed?" (git log/diff, deps, env) · search the exact error message in quotes · step away, bias accumulates. Re-run the EXACT original failing case before declaring victory; "seems to work" is not evidence. </when_stuck>
<on_complete> agentdb write-end '{"skill":"debug","bug":"","root_cause":"<what_broke>","fix":"<what_fixed>","test":"<regression_test_name>","learned":"<pattern_for_future>"}' </on_complete>