output-contract

name	output-contract
description	Shape the final output to user intent — concise answer vs implementation summary vs plan vs review report vs hand-off note. Use when producing the response the user actually receives.

Output Contract

The shape of the answer is part of the answer. A long essay when the user asked for a yes/no is wrong even when it is technically correct; a one-liner when the user asked for a report is wrong the same way.

When to use

• Writing the final response the user will read.
• Choosing between a short answer, a structured artifact, a summary of completed work, or a hand-off to another persona.
• The work is done and the question is "how do I tell them".

Procedure

1. Read the intent again. Direct question → direct answer. Artifact request → produce the artifact. Decision → present the decision and the trade-off, not the deliberation. Hand-off → contract for the next persona.
2. Match length to value. A one-line answer is not lazy; a five-page summary is not thorough. Length is in service of the user, not the writer.
3. Lead with the answer. Reasoning supports the answer; it does not delay it. Conclusions go first when the user is acting on them.
4. State residuals. What was assumed, what was skipped, what is uncertain. The user decides what to do with that.
5. Avoid trailing summaries. If the answer was already stated, do not restate it at the end.

Output

The shape that matches the intent: answer · artifact · summary-of-completed-work · plan · review · hand-off. Pick one; combine only when the user asked for a combination.

Anti-patterns to avoid

• Padding short answers with filler prose so they feel substantial.
• Truncating long-form artifacts to look concise.
• Restating the question, then the reasoning, then finally the answer.