Tighten Your Output

Tighten your output

A drift corrector for terseness discipline. 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 terseness discipline.

The discipline this re-anchors

Say it in fewer words or lines when nothing of value is lost. Two surfaces, resolved separately per the method doc's ladder.

Code, a standards convention owns this

The source of truth is the consuming organization's simpler-code convention: prefer the smaller form when it costs no correctness, readability, test coverage, observability, or convention conformance. Read it where it lives; re-anchor its two load-bearing parts rather than restating them:

• its named failure modes, the canonical smells a reduction must not introduce (speculative generality, the wrong abstraction, YAGNI);
• its constraints never traded for line count. Clarity, test coverage, error handling at boundaries, established conventions, and observability survive every cut.

When the consuming project declares no such convention, re-anchor that same shape as the portable baseline: fewer lines is the default only when none of those constraints is spent to get there.

Markdown. A flagged standards gap with a routing owner

Say the same thing in fewer words with no semantic loss. Drop filler, hedging, and restatement, never a directive, qualifier, threshold, or example. Tightening selects what to include; it does not compress prose into fragments, abbreviations, arrow chains, or jargon, and it keeps complete sentences a reader who did not watch the work can follow. When brevity and readability conflict, readability wins. Unlike the code side, prose terseness usually has no dedicated standards convention to discipline: when the consuming project's standards source declares one, route through it; when it does not, that is still a flagged gap (a candidate upstream standards addition), not license to invent a rubric in this skill.

The gap has a routing owner. /writing:be-concise holds the doctrine for prose a person reads, a ticket comment, a pull-request body, a doc, a status update, and it is where reader-facing text goes when the writing plugin is installed. Without it, reduce against the discipline above and say the point-first shape went unapplied. The operative safety net for prose reduction is a compress capability's semantic-diff discipline either way: route batch prose work there when that capability is installed, and otherwise run that same discipline in-thread rather than hand-rolling criteria here.

Audit. What to look for

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

• prose padded with filler, hedging, or a restatement of what an adjacent sentence already said;
• code carrying speculative parameters, dead branches, or hand-rolled boilerplate a built-in would replace;
• a long form kept where a shorter one loses nothing of value.

Correct each forward now, but only where the reduction is free: tighten the prose without dropping a directive/qualifier/threshold/example, and shrink the code without spending clarity, tests, error handling, conventions, or observability. When a cut would cost any of those, leave the longer form and say why.

Routing, where batch and proactive work live

• Prose a person reads → /writing:be-concise when the writing plugin is installed. It owns the point-first, scannable shape those readers need, which this corrector does not. Without that plugin, fall back to the markdown discipline above.
• Batch prose remediation → the docs-hygiene compress capability when that plugin is installed (its semantic-diff safety net is the guardrail for large prose cuts); otherwise run that same semantic-diff discipline as an explicit in-thread pass rather than hand-rolling a rubric here.
• Batch code reduction → the code-tidying batch-simplify capability over a change set when that plugin is installed; otherwise reduce in-thread against the simpler-code convention, spending no clarity, test, error handling, convention, or observability to do it.
• Proactive code-side enforcement is NOT here. It lives in review and design gates that cite the simpler-code convention; this corrector re-anchors the discipline and corrects the work in flight, it does not stand in for those gates.

Trigger ownership. One owner per brevity phrase

Two standing brevity postures exist, so the vocabularies are split rather than shared. The test is what the phrase names: the output in front of us, or an artifact a reader will open. A phrase that names neither is a register directive, and its default target is the conversation, so it stays here. Every phrase has exactly one owner, and neither description claims a phrase this table gives the other.

Once either skill is loaded, route by the target in front of you, not by the phrase that reached it; the sections above say where.

What this skill does NOT do

• Does not trade a constraint for brevity. A shorter form that spends clarity, a test, error handling, a convention, or observability is a wrong reduction, not a win.
• Does not invent markdown-terseness criteria. The consuming project's standard is still a flagged gap; the skill routes reader-facing prose to /writing:be-concise when the writing plugin is installed, and to the compress capability's discipline otherwise, rather than manufacturing its own rubric.
• Does not fabricate a finding. Work already at its tight form audits clean; say so.

Gotchas

• Terseness is not duplication. Removing a second copy of a fact is /discipline:point-dont-copy; removing wasted words from a single copy is this skill.
• The failure mode is over-cutting: a "concise" edit that quietly drops a qualifier or a boundary case has traded meaning for length. Judge every cut by what it costs, not by how many words it saves.