godmode-investigation
Skill6 starsChanged 3 months agoApache-2.0View on GitHub
Diagnose technical failures with reproducible evidence and bounded hypotheses. Use when a bug, regression, test failure, build failure, performance problem, or repeated unsuccessful fix needs root-cause investigation or a postmortem. Not for feature work or release mechanics.
In this repository22 other files it gives its agents.
- llms.txtllms.txt
- godmode-budgetSkill
- godmode-changelogSkill
- godmode-ciSkill
- godmode-codegraphSkill
- godmode-code-of-lawSkill
- godmode-continuitySkill
- godmode-evidenceSkill
- godmode-governanceSkill
- godmode-host-syncSkill
- godmode-impact-gateSkill
- godmode-loop-wardenSkill
- godmode-memory-gardenerSkill
- godmode-repairSkill
- godmode-replicateSkill
- godmode-researchSkill
- godmode-second-lookSkill
- godmode-skill-evalSkill
- godmode-skill-forgeSkill
- godmodeSkill
- godmode-spec-lifecycleSkill
- godmode-triageSkill
The file
We split this skill into the rules it gives an agent
7 rules. About 0 are common, 5 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈5
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 28
Run the smallest discriminating experiment.
- Distinctive: line 30
If one survived and the user requested a fix, create a regression check, implement one coherent remedy at the origin, and run the full …
- Distinctive: line 37
Do not implement when the user asked only for diagnosis.
- Distinctive: line 44
Do not repeat a failed hypothesis without new evidence.
- Distinctive: line 51
Prefer fresh command output, a minimal reproduction, traceable file/line references, content hashes, database migration state, and Git …
- Very specific: line 92
Read godmode-evidence-cycle.md for the attempt record and completion checklist.
- Distinctive: line 103
After a fix ships, run the postmortem in references/postmortem-flow.md.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Godmode Investigation
Outcome
Locate the earliest evidence-supported cause, test competing hypotheses until one survives its kill experiment, and either verify a focused remedy or state exactly what remains unknown.
Evidence cycle
- Restate the observed failure without proposing a fix.
- Reproduce it with the smallest reliable command or artifact, and record the incident
with that command:
godmode remember --kind incident "<what failed>" --repro "<the failing command>"runs it now and stores its red exit code. With no reproduction yet,--no-repro "<why>"says so (classed underspecified-ask). Record the environment dimension only when it materially changes the result; never dump the environment. - Trace the failing value or state backward across each relevant boundary. Capture inputs, outputs, status, and timestamps with secrets redacted.
- Compare with a working path in the same codebase and list every meaningful delta.
- Form at least two competing hypotheses, each with its cause, supporting evidence and a
kill experiment:
godmode hypothesis add --cause "<mechanism>" --kills "<check it predicts will pass>". One hypothesis tests a story's consistency, not its truth. - Run the smallest discriminating experiment. Change one variable.
godmode hypothesis kill <seq>runs a kill experiment and records whether it fired. - If one survived and the user requested a fix, create a regression check, implement one
coherent remedy at the origin, and run the full relevant verification. The fix claim
names the incident and the survivor:
godmode claim "<fixed ...>" --grade verified --cite "cmd:<the repro command>" --cite hyp:<seq> --fixes <incident-seq> --verify. It verifies only when the same reproduction command, red at the incident, is green now; a fix citing a hypothesis whose kill never ran, or fired, is refused.
Do not implement when the user asked only for diagnosis. Do not weaken, delete, skip, or rewrite a valid test to manufacture a pass. A mock must preserve the contract being tested and cannot replace the behavior under investigation.
Loop control
Record failed attempts with checkpoint --status failed --hypothesis ... --outcome ....
Do not repeat a failed hypothesis without new evidence. On the third failure of the same
hypothesis, stop changing code and revisit the architecture, boundary assumptions, or
test validity with the user. A different edit with the same causal claim is still the
same attempt.
Evidence quality
Prefer fresh command output, a minimal reproduction, traceable file/line references, content hashes, database migration state, and Git history over recollection. Treat agent reports, comments, and stale docs as leads until verified. Distinguish correlation, inference, and direct observation.
Handoff
Record the symptom, reproduction, confirmed or rejected hypothesis, evidence, attempted change, outcome, and next discriminating action. Generalize a private lesson only after the mechanism is understood. Report no broader success than fresh verification proves.
Before treating a report as new: recurrences --against "<the report>" matches it against the fixed registry's symptom column (docs/FIXED-REGISTRY.md) and names the row and its guard; precheck --about carries the same matches and the inventory or design lines that describe the feature, and a reply that calls something a product decision while such a line was never opened is named at Stop.
Deterministic support: loop detects repeated actions, reapplied patches,
oscillation, and a spent hypothesis from the records, and with --transcript
names a loop episode (one error signature, the same hunks, nothing new for six
attempts) with the turn where new information last arrived; mistakes runs the
recurring-failure detectors; method selects the RCA method from the evidence
shape and method --check-record refuses an incomplete one; reflect surfaces
contradictions with prior claims; integrity blocks test-weakening changes;
mistakes --process-started blocks an RCA against a stale process.
Absence protocol
An absence claim ("no callers", "0 rows", "not found") carries a control: or
second: citation or it is flagged: godmode mistakes' M21
(absence-without-control) fires on an absence claim that states its extent
(searched:/scanned:) but never proves the search mechanism itself could
have found something. An empty result from a broken probe reads identically
to a true negative - the control is what tells them apart. See godmode
claim --help for the full citation-prefix vocabulary.
Separately, and more strictly: a --grade verified absence claim recorded
via godmode claim needs TWO DISTINCT cmd: citations (or one that
positively enumerated something, not just came back empty) to avoid an
automatic downgrade to hypothesis - one probe that found nothing is
evidence about where you looked, not about what exists. This is the grading
pipeline's own gate and is a separate, stricter mechanism from M21 above; the
two are not unified, and citing control:/second: alone does not satisfy
it.
Read godmode-evidence-cycle.md for the attempt record and completion checklist.
Orchestration gate: before a fix is handed to another agent or a subagent, the
incident is on record with its reproduction (godmode remember --kind incident
--repro "<the failing command>") and the retest list is named (godmode atlas
closure <files>); a hand-off carrying neither is a guess passed along, and the
hand-back must cite the incident's seq and the retest's attestation.
Postmortem flow
After a fix ships, run the postmortem in references/postmortem-flow.md.
Verbs at the moment of demand
Each line names the one verb for the situation; run it then, not after.
- The same failure again:
godmode recurrenceslists repeated commands and failures before a third attempt;godmode error-patternmatches the failure text against declared patterns. - A hypothesis to test:
godmode hypothesis addrecords it with its kill experiment andgodmode hypothesis kill <seq>runs it;godmode experimentrecords the setup and outcome;godmode forecastrecords the prediction before the run so the result can refute it. - A postmortem to close:
godmode checklist template rcaprints the six RCA steps;godmode method --check-recordrefuses a record that skips one. - A source to read before judging it:
godmode read --source <name> --path <file> --lines a-brecords what was opened (path, lines, digest) so an absorb verdict can cite the implementing code rather than a README;godmode parity --sourcesshows which sources were read past the surface. - Two states to compare:
godmode differentialrecords both before the next edit;godmode replayre-reads a recorded run;godmode inspect <seq>opens one record in full. - A guard that must be proven:
godmode plantbreaks the target and shows the guard fails;godmode fuzzdrives the parser with malformed inputs;godmode scenariosruns the recorded scenario suite against the current tree. - Where a change reaches:
godmode topologymaps the call structure,godmode context whysays why a file is in context,godmode driftnames what moved since the last inventory. - Something silently swallowing errors:
godmode swallowlists the handlers and holds the committed ceiling. - A slow path:
godmode benchmarktimes it cold, andgodmode watchdogbounds a run that may not return;godmode watchfollows a file or log while the run is live.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

