---
name: rdc:fixit
description: "Usage `rdc:fixit <description>` — Quick fix under 5 files / 30 min that does not warrant a full plan→build cycle. Creates a minimal work item, makes the change, commits, runs a mandatory code-review pass (pr-review-toolkit:code-reviewer), closes. The only sanctioned bypass of rdc:build."
---

> **⚠️ OUTPUT CONTRACT (READ FIRST):** `guides/output-contract.md`
> Checklist-only output. No tool-call narration. No raw MCP/JSON/log dumps.
> One checklist upfront, updated in place, shown again at end with a 1-line verdict.

> If dispatching subagents or running as a subagent: read `{PROJECT_ROOT}/.rdc/guides/agent-bootstrap.md` first (fallback: `{PROJECT_ROOT}/.rdc/guides/agent-bootstrap.md`), then `{PROJECT_ROOT}/.rdc/guides/engineering-behavior.md` (fallback: `{PROJECT_ROOT}/.rdc/guides/engineering-behavior.md`).

> **Sandbox contract:** This skill honors `RDC_TEST=1` per `guides/agent-bootstrap.md` § RDC_TEST Sandbox Contract. Destructive external calls short-circuit under the flag.


# rdc:fixit — Sanctioned Quick Fix

## When to Use
- Typo or single-line text correction
- Config value change (env vars, constants, feature flags)
- Emergency hotfix that cannot wait for a full build cycle
- Dependency version bump
- CSS/styling tweak on a single component
- Broken import or export fix
- Single-file logic correction

## When NOT to Use — escalate to rdc:build instead
- New feature of any size
- Refactor touching >5 files
- Anything requiring architecture decisions
- Work that will take longer than 30 minutes
- Schema changes or migrations

## Arguments
- `rdc:fixit <description>` — fix the described issue

## Procedure

### 1. Scope check (mandatory — do this before touching any file)

Will this fix touch more than **5 files** or take more than **30 minutes**?

- **YES** → Stop. Use `/rdc:build` instead. Explain to the user why.
- **NO** → Continue.

### 2. Create a minimal work item (before touching any code)

```sql
SELECT insert_work_item(
  p_title     := 'fixit: <description>',
  p_item_type := 'bug',
  p_priority  := 'urgent',
  p_status    := 'in_progress',
  p_source    := 'fixit'
);
```

Note the returned `id`.

### 3. Write the fixit session marker

Write to `{USER_HOME}/.claude/fixit.marker`:
```
<work_item_id>
<ISO timestamp>
<description>
```

This signals the Stop hook that fixit is handling its own documentation.

### 4. Make the fix

Do the minimal work. Scope creep rule: if you discover the fix requires more than originally scoped, **stop immediately**:
1. Close the work item: `update_work_item_status('<id>', 'blocked', '["Escalated — scope exceeded fixit threshold"]')`
2. Delete the marker file
3. Tell the user to use `/rdc:build` instead

Apply `guides/engineering-behavior.md`: state material assumptions in the
implementation report, avoid speculative abstractions, touch only required
files, and verify behavior before moving the work item to `review`.

### 5. Commit

```bash
git add <specific files only — never git add -A for a fixit>
git commit -m "fix(<scope>): <description>"
if [ "$RDC_TEST" != "1" ]; then
  git push origin {development-branch}
else
  echo "[RDC_TEST] skipping git push origin {development-branch}"
fi
```

### 5.5 Mandatory code-review gate (before submitting implementation report)

⛔ **No fixit closes without a code-review pass.** Even single-file changes go through review.

Dispatch ONE `pr-review-toolkit:code-reviewer` agent on the fixit commit:

```
Agent({
  subagent_type: "pr-review-toolkit:code-reviewer",
  description: "fixit code review",
  prompt: "Review `git show HEAD` on the development branch. Focus on:
           bugs, logic errors, security, project-convention adherence (.claude/rules/*).
           Confidence-based filtering — high-confidence findings only.
           Return CODE_REVIEW_COMPLETE with: { critical_count, high_count, medium_count,
           low_count, findings: [{severity, file:line, issue, suggested_fix}] }."
})
```

**Severity gate:**
- `critical` or `high` findings → fix in this same fixit session (do not escalate to rdc:build for the fix itself; the original fixit owns the cleanup), re-commit, re-run review until clean
- `medium` or `low` findings → record in `implementation_report.flags`; proceed to close
- Zero findings → proceed to close

Under `RDC_TEST=1`: echo `[RDC_TEST] skipping code-review dispatch` and proceed.

### 6. Close and clean up

Submit implementation report first, move to review, then close as validator:

```sql
SELECT submit_implementation_report('<id>'::uuid,
  '{"tldr":"<one sentence>","assumptions":[],"deviations":[],"uncertainty":[],"detail":"<what was fixed>","flags":[],"transactional":false,"memory_records":[],"codeflow_post":{"agent_session_id":"<agent-session-id>","summary":"<what changed and why>","files_changed":["<path>"],"verification":["<command/evidence>"],"commit":"<hash optional>"}}'::jsonb
);

SELECT update_work_item_status('<id>'::uuid, 'review',
  '["Fixed via rdc:fixit; ready for validation"]'::jsonb,
  '<agent-session-id>',
  'agent'
);

SELECT update_work_item_status('<id>'::uuid, 'done',
  '["Validator verified rdc:fixit report, CodeFlow post, and checklist evidence"]'::jsonb,
  '<validator-session-id>',
  'validator'
);
```

If the fix touched a transactional flow, API boundary, or package contract, set `"transactional": true` and populate `memory_records` (see `agent-bootstrap.md`), then run:
```bash
node scripts/work-item-memory.mjs <work-item-id>
# Note: verify script exists first: ls {PROJECT_ROOT}/scripts/work-item-memory.mjs
# If the script is absent, skip this step and note it in the implementation report.
```

```bash
rm {USER_HOME}/.claude/fixit.marker
```

### 7. Confirm to user

Report: what was fixed, file(s) changed, commit hash. One sentence.

## Rules
- Work item created BEFORE any code change — never after
- `git add` specific files only — never `-A` or `.` for a fixit
- Branch: development branch always
- Never run `pnpm build` — not needed for a fixit
- If scope expands mid-fix: stop, escalate to rdc:build, don't finish under fixit
- Marker file must be cleaned up whether fix succeeds or escalates

## Capture lessons (exit step)

Before the final verdict line, follow `.rdc/guides/lessons-learned-spec.md` § Capture procedure. If this run taught something non-obvious — a first root-cause theory that turned out wrong, the documented/standard path not working, a missing gate or check that cost a round, or a surprising tool/infra behavior — write one `.rdc/lessons/<YYYY-MM-DD>-fixit-<short-slug>.md` per lesson using the schema in that spec. Set `scope` (`simple` | `architectural`) and `status` (`open`, or `applied` if you shipped the fix in this same run, with the commit linked). Commit the lesson file(s) on `develop` alongside the run's other commits, and note "N lessons captured" in your verdict/summary. A run that taught nothing writes nothing — absence is the default.