Skip to content
Development
Skill

/ca-refactor

Restructure code with behavioral parity proven through unmodified pre-existing tests, then refactor. No behavior change.

From plugin
codearbiter
14562 skills19 agents42 commands
Install
$ npx -y skills add arbiterForge/codeArbiter --skill ca-refactor --agent claude-code

How it fires

How this skill gets triggered: by you, by Claude, or both.

  • Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
  • You can call itInvoke it directly when you want it.
  • Slash command/ca-refactor

Context preview

The summary Claude sees to decide when to auto-load this skill.

Restructure code with behavioral parity proven through unmodified pre-existing tests, then refactor. No behavior change.

SKILL.md

ca-refactor.SKILL.md
name: ca-refactor
description: Restructure code with behavioral parity proven through unmodified pre-existing tests, then refactor. No behavior change.
argument-hint: "<surface and motivation>"

$ca-refactor — behavior-preserving restructure

The only permitted entry to refactor work. A refactor that cannot prove parity through unmodified pre-existing tests is a feature change in disguise and routes to `$ca-feature`. Two required parts: the **surface** (exact files, functions, classes, or methods — vague surfaces like "the auth module" are rejected) and the **motivation** (why the restructure is worth doing).

Flow

Routes to the `refactor` skill — six phases:

1. **Surface identification** — lock the exact files, symbols, and public signatures. 2. **Parity coverage proof** — demonstrate pre-existing tests already cover the named surface, with at least one direct test per public method. 3. **Red parity tests (conditional)** — if the refactor exposes a new test seam, route to `tdd` ([routines/tdd/SKILL.md](../../routines/tdd/SKILL.md)) Phase 1 to write failing tests pinning the seam's contract first. 4. **Implementation** — apply the restructure mechanically within the surface table; no new behavior, branches, error paths, or side effects. 5. **Parity verification** — the full pre-existing suite passes with zero edits to any pre-existing test file. 6. **Lint / coverage gate** — lint, type-check, and coverage clear; surface coverage MUST NOT regress.

Routes to

`refactor` ([routines/refactor/SKILL.md](../../routines/refactor/SKILL.md)) — all six phases.

When NOT to use

  • New behavior — a new branch, error path, side effect, public method beyond a Phase 3 seam, or a

change to what any input maps to → `$ca-feature`.

  • A change motivated by "the current behavior is wrong" → `$ca-fix`.
  • Questions or discussion → `$ca-btw`.
  • Persisting an already-completed refactor → `$ca-commit`.

Hard gate

No refactor proceeds without behavioral-parity coverage proof in Phase 2; if the surface is under-covered, the skill halts and routes to `tdd` Phase 1 to backfill before resuming. A Phase 4 diff that would classify as `feat`, or a Phase 5 verification that depends on edits to a pre-existing test, terminates the refactor and re-routes to `$ca-feature` or `$ca-fix`.

Read more
Ships withcodearbiter

When you can't trust yourself with your code base, trust Arbiter.

Get the whole plugin

Other skills on codearbiter.