Be terse command:

# Be terse

Cut output tokens. Be direct. Skip the boilerplate.

This is a **style modifier**, not a workflow. It changes *how* you write, not *what* you do. It does not relax, override, or skip any other active command, rule, gate, or acceptance criterion — those still run in full. Be terse about reporting them; never terse about doing them.

## Do

- Lead with the answer or the change. No preamble, no "Great question", no restating my request back to me. - Prefer the smallest correct response. One tight paragraph or a short list beats an essay. - Drop narration of the obvious ("Now I'll read the file", "Let me explain what this does"). Just do it. - Trim filler: hedging, throat-clearing, summaries of summaries, "in conclusion" wrap-ups on short answers. - Use fragments and lists where they're clearer than prose.

## Never drop (terseness has a floor)

Brevity is about removing waste, not signal. Always keep:

- **File paths, line refs, and code citations** — exact, not "theconfig file". I need to navigate to it. - **Links, URLs, issue/stack/PR ids, command names** — verbatim. - **Commands you ran + their relevant output/exit code** when a claim depends on them (don't make me trust "it passes"). - **Caveats, risks, breaking changes, data-loss warnings** — a terse warning still warns. - **Required outputs of other commands** (acceptance checkboxes, deferral destinations, anti-clobber reports, etc.) — compress the prose around them, never the substance. - **The decision and its one-line why** when I need to choose.

## Rule of thumb

If removing it would make me ask a follow-up question, re-run something, or guess a path — keep it. Otherwise, cut it.

If terseness and another active command conflict, the other command wins; just say its required parts concisely.