s4h-writing-report

这段内容是审核时保存的快照。外部来源才是完整且最新的版本。

---
name: s4h-writing-report
description: "Writes and audits business reports, briefing documents, and information reports for answer-first structure, precision, hierarchy, and navigability. Use when a report buries its findings, is written for the writer rather than the reader, or lacks clear structure. Triggers: 'write a report', 'report writing', 'business report', 'briefing document', 'information report', 'research summary', 'the report isn't clear', 'buries the findings'."
---

# Writing: Report

Reports fail when they are written for the writer rather than the reader. The writer knows the context, did the work, and wants to show the rigour of the process. The reader needs to know the answer, understand its implications, and decide what to do — usually in less time than the writer spent writing. These are incompatible objectives, and when the report serves the writer's needs, it fails the reader.

The most common report failures:

**Context before answer:** The report explains how the analysis was done before stating what it found. The reader who needs to act has to mine through methodology to find the claim.

**Findings without implications:** The report states what happened but not what it means. "Revenue declined 12% in Q3" is a finding. "Revenue declined 12% in Q3, driven primarily by a 31% drop in enterprise segment that is likely to continue unless the pricing model is revised" is an implication. Readers who need to decide need implications, not just findings.

**Vague quantification:** "Significant growth," "substantial decline," "many customers." These phrases communicate nothing. If a number exists, use it. If it doesn't, acknowledge the absence explicitly.

**Non-navigability:** A report that can only be understood by reading it from beginning to end has failed. The reader who needs the answer to one specific question should be able to find it. Section headers, a clear hierarchy, and an executive summary are not optional niceties — they are the delivery mechanism.

---

## Your Process

**Step 1: Reader's Question**
Who is reading this report, and what do they need to know and decide? State it specifically: not "the board needs to understand performance" but "the board needs to decide whether to approve the Q4 investment increase given Q3 performance." The reader's specific decision shapes every structural choice.

**Framing check:** Confirm the specific report and its reader before continuing. State what you've identified — the actual document being analyzed, its intended audience, and the core decision it must serve — in one sentence, then use `AskUserQuestion`:
- **Question:** "I'm reading this as: [your one-sentence framing of the report, its audience, and the decision it needs to serve]. Is that right?"
- **Header:** "Framing"
- **Options:**
  - **Yes — proceed** — framing is correct
  - **Adjust** — one element is off; user will correct it before you continue
  - **Reframe** — different situation than read; incorporate the correction before proceeding

**Step 2: Answer-First Check**
Does the opening section answer the main question before developing it? The first section of a well-structured report should contain the key finding and its primary implication, in plain language, before any methodology, context, or detail. Check: can a reader who only reads the first section make an informed decision?

**Step 3: Hierarchy**
Are sections ordered by importance? Does each section have a clear, functional header that tells the reader what the section will say (not just what topic it covers)? "Q3 Performance" is a topic header. "Q3 Revenue Down 12% — Enterprise Segment Driving Decline" is an answer header. Answer headers allow navigation; topic headers don't.

**Step 4: Precision**
Flag every instance of vague quantification or hedging language: significant, substantial, many, some, often, rarely, most. For each: is there a specific number available? If yes, use it. If no, state the absence: "data not available" o