# Repair In Place

> Fix a named defect in the lane's own worktree, briefed with the actual findings and without re-planning or widening scope. Use at REPAIR after verify or validate failed, when a landing bounced, or whenever the temptation is to re-read the requirement and start again.

- Skill: `niksavis/repair-in-place` (Agent Skill)
- Install (CLI): `npx skillmds@latest add niksavis/repair-in-place`
- Raw SKILL.md: https://api.skillmd.com/api/skills/niksavis/repair-in-place/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: niksavis (https://skillmd.com/u/niksavis)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/niksavis/repair-in-place

---

<!-- Generated by `basicly skills-build` from skill.yaml. Do not edit; edit the source. -->

# Repair in place

Repair is a **mode of the implementer**, not a fresh start. Same worktree,
same scope, same artifact. What differs is that you are briefed with findings
rather than with a requirement.

## Do not re-plan

The plan was already gated. Re-reading the requirement and reconsidering the
approach spends a second full build to reach the same place, and the rework
allowance is per gate — grinding through it is how a lane dies with nothing
landed.

If the finding shows the *plan* was wrong rather than the *code*, that is an
escalation, not a repair. Say so and stop.

## Fix in the lane's worktree

Never re-dispatch the lane to fix a named defect. A re-dispatch pays the whole
scope-reading cost again and arrives at the same defect with less budget. Hand
the finding to the worktree that already holds the context.

## Reproduce before you fix

Run the failing check and read its actual output first. Two things follow from
that and neither is optional:

- A fixture invented to match a suspected error message produces a fix for a
  failure that never happens. It has happened here: an unobserved error string
  made a retry path dead code through two consecutive "fixes".
- A gate's own repair advice can be wrong. Verify the premise before obeying
  the remedy — obeying one here deleted a real suppression on a lying gate's
  instruction.

## Fix the cause at every site, not the symptom at one

Before calling a single-site patch complete, check the other call sites. A
defect that reached one place through a shared helper reached the others too.

## Never weaken the gate that caught you

Not the tests, not the lint, not the type checker, and never `--no-verify`.
The cheapest way to pass a size gate is deleting comments — measured at 11-36%
of a module's tokens on this tree — and the cheapest way to pass a test is
loosening its assertion. Both leave the gate reporting green over a defect it
was built to catch.

## A fix ships its regression test

Write the test that fails first, then make it pass. A fix with no test is a
fix that will be made again.