Reuse or replace

A drift corrector for anti-fragmentation discipline: one way to do a thing,
not two. When an established way already exists, new work reuses it or openly
replaces it. It does not add a silent second way beside it. The method, re-anchor, audit the work in flight, correct forward, report, and the tone
that firing this is not an accusation, lives in
`${CLAUDE_PLUGIN_ROOT}/context/re-anchor-audit-correct.md`.
Read it; this file adds only what is specific to reusing or replacing an
established way rather than splitting into a parallel one.

The discipline this re-anchors

When a codebase, structure, or process already has an established way of
doing something, new work must not silently stand up a second, parallel
way beside it. Two coexisting ways of doing the same thing is fragmentation
It splits the reader's model, doubles the surface that drifts, and taxes
every future change with a "which one?" decision. Resolve the source of truth
per the method doc's ladder: if the consuming project states a
consistency / one-way rule in its own CLAUDE.md / .claude/rules/, re-anchor
THAT. Otherwise re-anchor this portable baseline.

Facing an established way, new work has exactly two honest options. The
two this skill is named for:

• Reuse it. Follow the established way, so the codebase keeps one way.
• Replace it. Openly argue the established way should change, then, if it
  should. migrate the old uses to the new way and record the decision.
  Replacement converges the codebase on the new single way.

The sin is neither of those: it is leaving the established way in place and
quietly adding a divergent way alongside it, so both now exist. That silent
second way is what this skill exists to catch.

Misconstrual guard. This is NOT "always conform" (mandatory)

Reusing is not blind conformity, and this skill never demands straight
obedience to the incumbent way. Replacing the established way is a
first-class, encouraged move, not a deviation to be suppressed. The
established way should be replaced when:

• evidence backs an improvement. Research or measurement shows a better
  way (route the evidence-gathering to /discipline:do-your-research, invoked via the
  Skill tool);
• its rationale is missing. Nobody can say why it is done this way ("I
  don't know, it just is");
• it rests on incumbency only. "we've always done it this way" is the
  sole support;
• it is stale or outdated. Newer developments may have superseded it;
  a challenge on this ground requires fresh research, not recall.

When you replace, do it in the open and carry it through: migrate the old uses.
When you reuse, reuse because the way holds up, not merely because it is there;
that interrogation is /discipline:reason-dont-recite's axis (below).

The burden rule. Divergence is priced by blast radius

Replacing the established way (or otherwise diverging from it) is allowed, but
it carries a burden: a stated rationale, recorded proportional to the
divergence's blast radius.

• Durable or architectural divergence, a new structural pattern, a
  different error-handling model, a second workflow. Records its rationale
  where durable decisions live: the repo's ADR or docs convention.
• Small, local divergence records it where the change is reviewed: the
  PR description or the commit message.
• No recorded reason at all is the finding. An unexplained second way is
  fragmentation whether or not it is defensible on its merits, the burden is
  to say why, not merely to be right.

Scope, the unlintable "approach" level

This skill owns consistency of how work is done where judgment, not a
tool, decides it: code idioms and shapes, module and file structure, naming
shapes, error-handling and logging approaches, API and interface conventions,
documentation formats, and process or workflow choices.

Mechanical style is out of scope. Indentation, quote style, import
order, line length, and everything a formatter or linter settles
deterministically belong to those tools, not to a judgment corrector. This
skill fires at the level a linter cannot reach: the approach, not the
whitespace.

Distinct axes, the two skills this must not be confused with

Firing this cleanly requires keeping it apart from two siblings; the
boundaries are deliberate, not incidental.

• /discipline:reason-dont-recite (evaluation-side). That skill
  interrogates inherited content. Is this existing convention actually
  justified, or coasting on precedent? This skill is production-side:
  when creating new work, reuse the established way unless you state a
  reason to replace it. They meet at the challenge: when this skill's audit
  finds you want to replace the established way, the question "is the
  established way even right?" is reason-dont-recite's, and the evidence for a
  better way is /discipline:do-your-research's. Reuse-or-replace governs the
  second way; those govern the justification.
• /discipline:pick-for-the-problem (carve-out. Does NOT overlap). That
  skill governs selecting a tool, library, framework, or dependency to fit
  the problem, and names incumbency as a selection sin. This skill
  never governs that selection. Consistency of idioms, structure, and
  process is reuse-or-replace; choosing what tool or dependency to adopt is
  pick-for-the-problem, where matching the incumbent choice can be exactly
  the wrong reflex. Do not apply this skill to a build-vs-buy or
  which-library decision. Route it there.

Audit. What to look for

Name concrete, located findings (per the method doc's step 2, self-audit):

• a new pattern, idiom, or structure standing beside an existing one that
  already solves the same thing, with no stated reason for the second way;
• a divergent error-handling, logging, naming, or interface approach
  introduced where the codebase already has an established one;
• a second workflow, process, or document format added alongside the
  established one rather than reusing or replacing it;
• a divergence whose blast radius is durable/architectural but whose
  rationale was never recorded in the repo's ADR/docs convention;
• a small local divergence with no rationale in its PR or commit;
• an established way reused only because it is there, where its rationale
  is missing, incumbency-only, or stale, a challenge that was owed and
  skipped (route to /discipline:reason-dont-recite /
  /discipline:do-your-research, invoked via the Skill tool).

Correct each forward now: reuse the established way for the new work; or,
where replacement is warranted, record the rationale at the blast-radius-
appropriate level AND, if the established way is genuinely superseded, migrate the existing uses and retire it rather than leaving both. Never settle
for the silent second way.

What this skill does NOT do

• Does not mandate conformity. A well-grounded replacement that supersedes
  the established way and migrates its uses is a correct outcome, not a
  violation; the duty is to keep one way, not to freeze the incumbent one.
• Does not police mechanical style. Formatting and lint-settled choices
  belong to the linter/formatter; this skill audits the unlintable approach
  level only.
• Does not govern tool or dependency selection. That is
  /discipline:pick-for-the-problem; incumbency there is a selection sin, not
  a consistency target.
• Does not fabricate a finding. New work that already reuses the
  established way, or replaces it with a recorded reason, audits clean; say so.

Gotchas

• The tell is two ways where one would do, not divergence itself. A
  single replacement that openly superseded the old way (uses migrated,
  decision recorded) kept the codebase on one way; it is the goal, not the
  finding. The finding is the old way and the new way both left standing.
• "Be consistent" read as "never replace" inverts the skill. Blind trust in
  the status quo is the failure mode on the other side; the misconstrual
  guard exists because straight conformity is not the goal. One way is.
• A recorded reason is the burden, not correctness. An unexplained second way
  is a finding even if it would have been defensible; the fix is to state the
  rationale (and keep one way), not to argue the divergence was fine.