Install
$ agentstack add skill-agent-rig-rig-rig-debug ✓ scanned · ✓ verified, works with Claude Code, Cursor, and more.
Security review
✓ PassedNo issues found. Passed automated security review. · v0.1.0 How review works →
- ✓ Prompt-injection patterns
- ✓ Secret / credential exfiltration
- ✓ Dangerous shell & filesystem operations
- ✓ Untrusted network calls
- ✓ Known-malicious package signatures
What it can access
- ✓ Network access No
- ✓ Filesystem access No
- ✓ Shell / process execution No
- ✓ Environment & secrets No
- ✓ Dynamic code execution No
From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.
Verified badge
Passed review? Show it. Paste this badge into your README, it links to the public security report.
Reliability & compatibility
Declared compatibility
Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.
We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps, measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.
How agent discovery & health will work →About
Debug
Drive a bug to root cause and a single minimal fix using the four-phase methodology.
Configuration
Reads .rig/config.json:
test.command— how to run the test suite when collecting Phase 1
evidence (default: npm test).
agents.debugger— the project's name for the canonicaldebugger
role (default: debugger).
agents.architect— the project's name for the canonicalarchitect
role, used only when escalating (default: architect).
If the file is absent, use the defaults above and note you're running unconfigured.
The four-phase methodology
The debugger agent runs this loop; the skill drives it and refuses to let it skip ahead. Each phase has a deliverable that gates the next:
- Phase 1 — Root cause. Gather evidence: reproduce the failure, read
the failing code path, capture the exact error/stack/trace, git diff the suspect window. Deliverable: a stated root cause backed by observed evidence — not a guess.
- Phase 2 — Pattern analysis. Ask whether this is an instance of a
class. Does the same bug shape exist elsewhere in the tree? Deliverable: the blast radius (this one site, or N sites).
- Phase 3 — Hypothesis. State the specific change that should fix the
root cause and why, plus how you'll confirm it. Deliverable: one falsifiable hypothesis.
- Phase 4 — Minimal fix. Apply the smallest change that addresses the
root cause, add/extend a test that fails before and passes after. Deliverable: root cause + fix + test.
Arguments
$ARGUMENTS is a one-line description of what's broken. Examples:
test suite fails with a database connection-closed errorthe workspace-commit step times out on a fresh worktreePR #519 deprovision workflow leaves orphaned resources behind
If $ARGUMENTS is empty, ask the user for the symptom in one sentence. Don't start the loop on a vague brief.
How it runs
- Print the brief. Restate the bug in one line so the user sees
you understood it correctly.
- Spawn the
debuggeragent (mapped throughagents.debugger) with
the brief, the working directory (current cwd), and any obvious context (the failing test name, the production trace ID, the relevant ticket). Tell it to start at Phase 1 and not propose fixes until Phase 1's deliverable is in.
- Read the agent's report. It comes back at one of these states:
Phase 1 incomplete — need→ either run the data
collection yourself (run the test command from .rig/config.json (test.command, default npm test) scoped to the failing test, fetch logs, git diff) or ask the user. Then re-spawn the debugger with the data added.
Phase 4 complete — root cause, fix, test→ done. Report to
user with the agent's output. The fix is already in the worktree.
Three fixes failed — architectural concern→ STOP. Surface the
agent's architectural-concern note to the user. Do not spawn the debugger again with "try one more thing." Suggest re-scoping or pulling in the architect agent (mapped through agents.architect) for a design review.
- After a Phase 4 fix, hand back to the user. Don't auto-PR.
Debugging produces a candidate fix; the user decides whether to ship it.
Anti-patterns this skill exists to prevent
- Coder agent invoked on a bug with "fix this" — coder writes a
plausible patch with no root cause. Bug returns later.
- Multiple speculative fixes piled into one commit. Can't tell what
worked, can't revert cleanly.
- Architectural problems repeatedly patched at the symptom layer
until they metastasize.
Relationship to other skills
- Use
/rig-debugwhen you don't know why something fails. It refuses
to guess.
- Use an implement-style flow when you know what to build. It assumes
the spec is correct.
- Use a verify flow to confirm a known-good change works end-to-end —
not for debugging an unknown failure.
/rig-debugmay end with a follow-up ticket if the fix is big enough to
warrant one; usually it just ends with a small worktree change the user reviews directly.
Source & license
This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.
- Author: agent-rig
- Source: agent-rig/rig
- License: MIT
Install and usage instructions live in the source repository linked above.
Reviews
No reviews yet, be the first.
Write a review
Versions
- v0.1.0 Imported from the upstream source.