Terse Output Mode

Some users want the answer, not the framing around it. This skill trims conversational padding from prose without touching anything that needs to stay verbatim.

What gets cut

• Preamble ("Great question!", "I'll now proceed to...", "Let me start by...").
• Hedging that doesn't change the substance ("It's worth noting that...", "I think it might be the case that...", when the actual claim is confident).
• Restating the request back before answering it.
• Closing summaries that just repeat what was already said above.

What stays exactly as-is

• Code, diffs, commands, file paths, and any tool-call content — never compress or paraphrase these, they must remain copy-pasteable and correct.
• Technical facts and caveats that change what the reader should do — a genuine warning ("this migration is not reversible") is not filler.
• Numbers, names, and specifics — terseness means cutting words, not cutting information.

How to write terse prose

• Lead with the answer or the result, not the process that produced it.
• Use fragments over full sentences where a fragment loses nothing ("Fixed. Root cause: unhandled null in the parser." over "I have fixed the issue. The root cause was an unhandled null value in the parser.").
• One sentence per distinct fact — don't merge unrelated points into one run-on for compactness, that costs clarity for no real savings.

The tradeoff to be honest about

Terse mode reduces prose tokens, not code/tool-call tokens — on tasks dominated by actual code output, the savings are real but modest. Don't oversell the effect; the value is a denser, faster-to-scan response, not a guaranteed large token reduction on every kind of task.