القائمة
Use when diagnosing a bug, flaky test, unexpected behavior, or production incident, before proposing or writing any fix. Invoke via route or explicit command.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | debug |
| description | Use when diagnosing a bug, flaky test, unexpected behavior, or production incident, before proposing or writing any fix. Invoke via route or explicit command. |
NO FIXES WITHOUT ROOT CAUSE.
This is a hard rule, not a preference. A fix without a root cause is a guess that happened to change the symptom. If you are about to change code to make a bug go away and you cannot state the root cause it addresses, stop.
Before theorizing, build a repro: a command whose output differs depending on which hypothesis is true. Run it before proposing a fix. A hypothesis picked without a command that can distinguish it from the alternatives is a guess, not a diagnosis.
Any claim about behavior needs the exact command and its output pasted in the message that makes the claim. "seems to happen when..." without a paste is speculation. This applies to your own claims and to a subagent's report about the bug — re-run it yourself before repeating its conclusion.
Every hypothesis gets one line in memory-progress.md, written as it is formed, not after it resolves:
HYP <n>: <hypothesis> → <experiment> → <result>
Example:
HYP 3: server closes idle SSE conns after 55s → curl -N, hold idle 70s, grep server
log for FIN → confirmed, server-side timeout fires at 55s
End every debugging session with the current hypothesis state written this way, even when unresolved — "no narrowed hypothesis yet" is a valid result; a missing line is not.
Ten ways to build a repro. Pick the cheapest one that distinguishes your hypotheses; do not reach for the heaviest by default.
curl against the endpointtsx/go run scriptgit bisect or manual halving) to the introducing commit-race, or the equivalent for the language)Temporary instrumentation — a log line or print added only to test a hypothesis — is
tagged DBG-<topic> (for example DBG-sse-drop), so it is greppable. Before any
commit: grep -rn "DBG-" <path> and remove every hit, or confirm the search returns
none. A DBG- tag left in a commit is unfinished cleanup, not something to skip.
Instrument at the boundary whose two sides you're trying to distinguish, not upstream or downstream of it. If the hypothesis is "the client drops the connection vs. the server closes it," the seam is the socket between them — instrumenting only the client cannot tell you which side initiated the close.
Thirty minutes without a narrowed hypothesis: stop where you are. Write the HYP ledger line for the state you have, then step back to an architecture read — re-read the relevant design doc or code path from the top before running another instrumented attempt. Continuing to poke at the same layer past thirty minutes without a hypothesis is a sign you're missing structure, not a shortcut to one.
Three failed fixes at the same site (same function, same file, same layer) mean the defect is upstream of that site. Stop patching there. Escalate to design/architecture level — the real fix belongs somewhere else in the system, not in a fourth variant of the same patch.
A production incident (failures happening now, in prod) is diagnosed differently: mitigate before you diagnose. Mitigation means whichever of these stops the failures fastest — flag off, roll back, pause the queue. Root-cause work does not begin until mitigation is in effect, and never replaces it. Once the incident is stable, root-cause work becomes a WIP line with a named owner and a real next action — never waived, and never silently dropped once traffic recovers:
**WIP** root-cause: <incident> — next: <exact investigation step>, owner: <name>
A leisurely investigation while failures continue is the wrong order, and so is closing the incident once it's mitigated with no root-cause line at all.
Check for the environment's language- or browser-specific debugging skills, when
installed, before improvising instrumentation — for example golang-troubleshooting
for Go runtime issues, a benchmarking skill for a performance question, or Playwright
tools for a browser flow. Use them when they exist; this skill's loop still applies
underneath — repro first, evidence gate, HYP ledger.
| Thought | Reality |
|---|---|
| "The fix is obvious, skip root cause" | Symptom fixes recur; find the cause |
| "One more print will crack it" | No hypothesis, no instrument — write the HYP line first |
| "It's in prod, just ship the real fix now" | Mitigate first; root cause follows as a WIP line, never skipped |
| "I've patched this spot before, one more try" | Three strikes here means the defect is upstream — stop patching, escalate |
Use once a spec is approved and ready to become an executable task list — turns spec requirements into a wave-based plan of write-scoped, testable tasks that waves can dispatch. Invoke via route or explicit command.
Use when a plan already exists and is ready to run — dispatches each wave's tasks, reviews every return before trusting it, and gates advancement on evidence. Invoke via route or explicit command.
Use when writing a new galdr skill, editing an existing one, or running the pack's quarterly prune review.
Continuation protocol for resuming work after a break, handing off to another session, a subagent, or Codex, and parking fast under a usage limit. Invoke via route or explicit command.
Use once per repo to create or refresh docs/agents/galdr.md — the config verify, waves, review, branches, and route read for gate commands, invariants, models, and smoke details. Slash-command only, not router- or model-invoked.
Use when the user runs /galdr:core to install, uninstall, or check galdr's core rules block on this machine for Claude, Codex, or Antigravity. Run install once per agent to write the marked block into that agent's rules file (or the Claude enabled flag); uninstall to remove it; status to report state without writing.