Reuse Or Replace

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 judgement, 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 judgement 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.