Investigate-then-decide root-cause analysis for a defect whose cause is unknown (distinct from /fix, which assumes a known bug). Five gated phases: capture, hypothesize, gather, decide, hand off. Investigation only, no code changes; exits to /fix, /adr, or a no-action close.
npx skills add https://github.com/arbiterForge/codeArbiter --skill ca-debug
Find the cause first, fix it never. debug investigates and routes; it does not touch code. It drives one closed loop — reproduce (Phase 1) → confirm by cited evidence (Phases 2–3) → hand /fix a regression test that re-runs the repro and must pass (verify). The minimal repro is the anchor that closes the loop; code changes belong to /fix.
Read these, or STOP and surface the gap — never guess a log path, trace tool, or test runner:
${CLAUDE_PROJECT_DIR}/.codearbiter/tech-stack.md — log paths, trace tooling, test runner conventions. The evidence sources.${CLAUDE_PROJECT_DIR}/.codearbiter/CONTEXT.md — domain vocabulary, system structure, and the stage: frontmatter (the maturity value; higher demands more rigorous evidence before exit).${CLAUDE_PROJECT_DIR}/.codearbiter/security-controls.md — only when the symptom touches a security boundary (auth, crypto, secrets). Optional; absent on most defects.The user MUST supply at least a one-sentence symptom. If absent, ask for one — do not guess the symptom.
Record the symptom with enough fidelity that another operator reproduces it without further questions:
If no minimal repro exists, derive one with the user before continuing. An intermittent issue still has a trigger condition (an input pattern, a load condition, a timing window) — capture that.
Gate: a minimal repro, or a documented intermittent-trigger profile. A symptom without one cannot be debugged, only speculated about. Every piece of evidence MUST cite its source.
Produce at least three distinct candidate causes, ranked by likelihood, before gathering any evidence against them. Distinct means different subsystems, mechanisms, or failure modes — not three rewordings of one suspicion.
For each candidate write: a one-sentence hypothesis, the subsystem/boundary involved, and the mechanism by which it produces the observed symptom. Number them H1, H2, H3… for Phase 3.
Rank by recency of relevant changes (recent commits to the suspect subsystem raise rank), symptom specificity (a symptom pointing narrowly at one mechanism raises it), and historical pattern.
Include at least one boring hypothesis — environmental drift, dependency version change, config mismatch, stale cache, operator error. List it even if ranked last. Confirmation bias toward exotic causes is the recurring debug failure mode.
Gate: three or more distinct hypotheses, one of them boring. Single-hypothesis lock-in is the single most common cause of misdiagnosis — the gate forces breadth before depth.
For each hypothesis, identify what would confirm or refute it, then gather that evidence by reading existing artifacts only. No code is modified in this phase.
For each H1…HN write the CONFIRM signal, the REFUTE signal, and the source where each lives (log file, trace tool, commit range, metric dashboard). Then read:
tech-stack.md.git log, git diff) on suspect paths.Annotate each hypothesis CONFIRMED, REFUTED, or INCONCLUSIVE, with a cited source. Do not collapse INCONCLUSIVE to CONFIRMED or REFUTED by inference — state what additional evidence is needed and where it lives. New hypotheses that emerge are added and gathered against; Phase 2 is a floor, not a ceiling.
Gate: no code change of any kind — no edit, no refactor, no "try a fix." A hypothesis testable only by changing code becomes a Phase 4 finding (exit (a), with a regression test obligation), not a change here. No INCONCLUSIVE evidence promoted to CONFIRMED without a cited source.
Walk the evidence ledger and pick exactly one exit. "We'll figure it out later" is not an exit.
/fix. One hypothesis is CONFIRMED by cited evidence and the disposition is a code change. Carry: the hypothesis ID and statement, the cited confirming evidence, and a named regression test obligation — a one-sentence description of the test /fix MUST write (and watch fail) before any fix code. It MUST encode the Phase 1 minimal repro, so the exact condition that reproduced the defect becomes the test that proves it fixed — this is what closes the reproduce→fix→verify loop. /fix refuses to proceed without it./adr. The system behaves as currently specified, but the specification itself is in question. Carry: the hypothesis ID and statement, a one-sentence statement of the ambiguity, and the symptom record plus evidence ledger as context. An ADR is authored only via /adr with explicit user attribution — surface the question to the user and obtain attribution; never author the ADR autonomously as the disposition of a debug session.If a finding is real but out of scope for any of the three exits, mark it inline with [NEEDS-TRIAGE] and continue — do not stall on it.
If no exit can be chosen — all hypotheses INCONCLUSIVE — loop back to Phase 3 for more evidence, or take exit (b) and surface the open question. "No decision" is not a valid exit.
Gate: exactly one of (a) / (b) / (c) is named. Exit (a) carries a regression test obligation. Exit (b) carries the ambiguity statement and user attribution before any /adr. No exit closes on "more investigation needed" without either looping to Phase 3 or selecting (b).
Emit a summary downstream skills can consume without re-reading the session, then route:
/fix with the confirmed bug statement, cited evidence, and named regression test obligation. The orchestrator routes /fix to the tdd skill in bug-fix variant, where that test becomes the Phase 1 obligation that must fail before fix code. debug does not pre-write the test./adr with the ambiguity statement, symptom record, and evidence ledger attached as context, with user attribution.python3 "${CLAUDE_PLUGIN_ROOT}/hooks/taskwrite.py" add "<symptom>" --desc "<no-action rationale>" (add --id debug.note to mint a dotted ID; optional for a debug note). The helper owns the schema the SessionStart hook and statusline parse, so a note recorded this way cannot drift from it, and it is the only writer .codearbiter/open-tasks.md's protected-state class admits. This keeps the note in the in-flight count as an open item to revisit rather than a bare bullet. No further handoff.Surface the summary and the handoff to the user before the skill exits.
Gate: the handoff is routed. Exit (a) carries an explicit regression test obligation. Exit (c) is recorded before close.
/fix./fix, (b) ambiguity → /adr, or (c) no-action close./fix for a bug not yet confirmed by cited evidence — /fix is for known bugs./fix to carry into its TDD Phase 1./adr.tech-stack.md or STOP.Guide for creating high-quality MCP (Model Context Protocol) servers that enable LLMs to interact with external services through well-designed tools. Use when building MCP servers to integrate external APIs or services, whether in Python (FastMCP) or Node/TypeScript (MCP SDK).
Automatically creates user-facing changelogs from git commits by analyzing commit history, categorizing changes, and transforming technical commits into clear, customer-friendly release notes. Turns hours of manual changelog writing into minutes of automated generation.
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup
Guide for creating high-quality MCP (Model Context Protocol) servers that enable LLMs to interact with external services through well-designed tools. Use when building MCP servers to integrate external APIs or services, whether in Python (FastMCP) or Node/TypeScript (MCP SDK).
React Native and Expo best practices for building performant mobile apps. Use when building React Native components, optimizing list performance, implementing animations, or working with native modules. Triggers on tasks involving React Native, Expo, mobile performance, or native platform APIs.
React and Next.js performance optimization guidelines from Vercel Engineering. This skill should be used when writing, reviewing, or refactoring React/Next.js code to ensure optimal performance patterns. Triggers on tasks involving React components, Next.js pages, data fetching, bundle optimization, or performance improvements.
Next.js best practices - file conventions, RSC boundaries, data patterns, async APIs, metadata, error handling, route handlers, image/font optimization, bundling
Use when starting feature work that needs isolation from current workspace or before executing implementation plans - creates isolated git worktrees with smart directory selection and safety verification
Take arbiterforge/codearbiter-ca-debug from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.