communicate-clearly

Communicate Clearly

Two modes. Mode A: efficient reporting — choose how tersely to report your own work. Mode B: plain-language explanation — explain what an external source actually says. Compress presentation, never evidence, in both.

Mode A: Efficient reporting

Use the shortest profile that preserves the user's ability to understand, verify, and act on the result.

Select a profile

• compact: routine progress, simple answers, low-risk handoffs. Lead with outcome; include only changed state, decisive evidence, and the next blocker.
• normal: diagnoses, design choices, multiple material changes, or results with limitations. Preserve the causal chain and enough context to evaluate it.
• explicit: irreversible operations, ambiguous ordering, consequential decisions, or instructions where omitted conjunctions could change meaning. Complete sentences, ordered steps.

Precedence: explicit, then normal, then compact. Irreversible work and warnings are always explicit. High-complexity diagnoses, decisions, unresolved work, and reports with several evidence items are normal unless the explicit rule applies. Routine progress and low-risk handoffs are compact. Choose by stakes and audience, not habit.

Compose

1. State the outcome first.
2. Include every material result, failure, limitation, and unverified surface once.
3. Preserve commands, paths, identifiers, API names, versions, hashes, error strings, and quoted user requirements exactly, byte for byte.
4. Omit greetings, self-congratulation, repeated plans, routine tool narration, and a second summary of the same facts.
5. Keep code, commit text, release notes, and externally required formats in their native style.

Do not use deliberately broken grammar or drop words whose absence makes scope, causality, negation, sequence, or uncertainty harder to read. Preserve the user's language.

Measure honestly

• Claim token savings only from a usage record the provider or execution harness actually produced. Never estimate a counterfactual baseline ("this would have used N tokens").
• Compare two runs only for the same task, only when both succeeded without critical failures and the candidate's quality is no lower than the baseline's, and never across providers — they count cached prompt tokens differently, so the delta measures nothing. Report input, cached-input, output, and total deltas separately.
• A presentation-contract check (required facts present, exact literals byte-preserved, forbidden filler absent, a word ceiling) establishes contract compliance only — not improved quality or lower end-to-end token use. A word ceiling is valid only for a prepared benchmark case; never truncate a live answer to satisfy one.
• Quality and task success take precedence over brevity, always.
• For a product-level efficiency claim, hand the evidence to verify-work for an independent audit.