fix

Fix a confirmed bug: a failing regression test first, then a minimal fix, then the rest of the tdd gates.

What it does

This is the entry point for a defect that already has a known cause, or one you can describe precisely — what’s happening versus what should happen, ideally with a stack trace or a way to reproduce it. The work routes into the standard test-first pipeline, but the first obligation is framed around proving the bug rather than building something new: a test has to fail, and fail for the specific reason the defect causes, before any correction is written. Only after that red test is confirmed does the minimal fix land, followed by the same review and verification steps every other change goes through.

Usage

/ca:fix <what's happening vs. what should happen>

Describe the observed behavior and the expected behavior; a stack trace or reliable reproduction sharpens the diagnosis.

Example

> /ca:fix search results page shows a blank page instead of "no results" when a query matches nothing

Reproducing... confirmed: empty result set triggers an unhandled render path in SearchResults.
Root cause: the component assumes results.length > 0 and never checks the empty case.
Writing regression test: renders SearchResults with an empty array, expects "no matches" text.
Running... FAIL (expected reason: TypeError reading results[0], matches the observed defect)
Test is red for the right reason. Proceeding to the minimal fix.

When to reach for it

Reach for /ca:fix once the cause is known or you can name a precise repro. If the cause is unknown, /ca:debug investigates first and hands off a confirmed bug statement /ca:fix can act on.

Gates

Gate	When	Effect
regression test first	before any fix code is written	a test reproducing the defect must exist and fail for the right reason
root cause named	before the failing test is written	the exact code path producing the wrong behavior must be located, not guessed at

Source

Source — plugins/ca/commands/fix.md (v2.9.1)

---
description: Fix a confirmed bug: a failing regression test first, then a minimal fix, then the rest of the tdd gates.
argument-hint: "<what's happening vs. what should happen>"
---

# /ca:fix — regression-first bug fix

The only permitted entry to bug-fix work. No fix code is written before a regression test reproduces the defect and goes red for the right reason. Give the observed behavior and the expected behavior, plus a stack trace or reproduction when you have one.

**Orientation:** if `.codearbiter/code-map.md` is present, read it before diagnosing — a coarse concern→path→role map that helps locate the defect. Absent is fine; it is read-on-demand.

## Flow

Routes to the `tdd` skill, bug variant — Phase 1 is framed around confirming the defect, not building
new behavior:

1. **Reproduce** the bug consistently.
2. **Locate the root cause** — the exact code path producing the wrong behavior.
3. **Write a regression test** that fails in the current state for the precise reason the bug causes
   (not an unrelated error).
4. **Confirm it's red for the right reason** — the failure message matches the described defect.

Only then does `tdd` proceed: minimal fix to green, then the remaining `tdd` gates. The implementation
agent (`backend-author`, `frontend-author`, or `infra-author`) is selected by where the bug lives. If
the defect cannot be pinned by a failing test, STOP and surface the question.

## Routes to

`tdd` (`${CLAUDE_PLUGIN_ROOT}/skills/tdd/SKILL.md`) — all phases, Phase 1 framed for bug confirmation.

## When NOT to use

- New behavior → `/ca:feature`.
- A behavior-preserving restructure → `/ca:refactor`.
- "Why does it do this?" → `/ca:btw`.
- Persisting fix code already written → `/ca:commit` (the gates still apply).

## Hard gate

MUST NOT write fix code before the regression test is red for the right reason. MUST NOT accept a test
that passes against the broken state as proof of the defect.

View in repo

fix