Receber por email
← Voltar para o catálogo

report-writing

This skill should be used when the user asks to "write a report", "executive summary", "research report format", "report structure", "present findings", "business writing", "analysis documentation", or needs guidance on structuring research outputs, executive communication, or professional report formatting.

20estrelas
Atualizado há 2 meses

Ver no GitHub ↗ Licença: MIT

Como adicionar

/plugin marketplace add zircote/sigint

O comando exato pode variar conforme o repositório. Confira o README no GitHub.

Para o autor da skill

Cole no README do seu repo

Mostra que sua skill está catalogada na Skillteca, gera backlink e tráfego rastreável.

[![Skillteca](https://www.skillteca.com.br/api/badge/report-writing-zircote/svg)](https://www.skillteca.com.br/skills/report-writing-zircote)

Alerta por categoria

Receba novas skills de Escrita e Conteúdo toda segunda

1 email curto, só com as skills novas de Escrita e Conteúdo. 4 minutos de leitura, sem spam, cancela com 1 clique.

Você confirma o email no primeiro envio. Sem spam. Cancela com 1 clique.

Ler descrição completa

Report Writing

Overview

Report writing transforms research findings into clear, actionable documents for decision-makers. This skill covers best practices for structuring, writing, and visualizing market research outputs.

Critical Rules

  1. ALWAYS start with the Executive Summary — no report should open with methodology, background, or definitions. The first substantive section must state the bottom-line findings and recommendation.
  2. NEVER fabricate data — if a number is not provided, say so explicitly. Present ranges when sources disagree. Use hedging language ("data suggests", "estimated") for uncertain claims.
  3. EVERY finding must have a "so what" — orphan facts that don't connect to implications or recommendations waste the reader's time.
  4. ALWAYS use active voice — passive voice obscures who did what. Write "Stripe captured 40% share" not "40% share was captured by Stripe".
  5. ALWAYS include at least one Mermaid diagram — visualization is not optional. Use pie charts for composition, quadrant charts for positioning, state diagrams for scenarios.
  6. Recommendations MUST include What/Why/How/Risk — vague recommendations ("consider expanding") are useless. Be specific and actionable.
  7. Preserve exact data from the user — do not round, reinterpret, or omit numbers the user provides. Every data point given must appear in the output.
  8. Match report type to audience — executive briefs for C-suite (1-2 pages), research summaries for VPs (3-5 pages), full reports for analysts (10-30 pages).

Report Type Selection

When the user does not specify a report type, use this decision table:

| Signal in User Prompt | Default Report Type | |----------------------|-------------------| | "executive brief", "for the CEO", "quick summary" | Executive Brief | | "research summary", "3-5 pages", "for VPs" | Research Summary | | "full report", "comprehensive", "detailed", "include everything" | Full Report | | "data pack", "supporting data", "appendix only" | Appendix/Data Pack | | No clear signal | Research Summary (safest default) |

Report Types

Executive Brief (1-2 pages)

  • Key findings only
  • Single recommendation
  • For: C-suite, board
  • Time to read: 5 minutes

Research Summary (3-5 pages)

  • Main findings with evidence
  • Multiple recommendations
  • For: VPs, directors
  • Time to read: 15 minutes

Full Report (10-30 pages)

  • Comprehensive analysis
  • Detailed methodology
  • For: Analysts, implementers
  • Time to read: 30-60 minutes
  • MUST include: Table of Contents, at least 6 major sections, Appendix with methodology and data sources. Include quadrantChart for competitive positioning only when a competitive dimension is present in the findings. Include stateDiagram for scenario analysis only when scenario or trend data is available

Appendix/Data Pack

  • Supporting data
  • Detailed tables
  • For: Deep dives
  • Reference as needed

Document Structure

Executive Summary (Always First)

The Executive Summary is the most important section of any report. It must stand alone as a decision document — a reader who reads only the Executive Summary should know the key findings, the recommendation, and the primary risk.

Length: 1 paragraph to 1 page Content (in this order):

  1. Context (1 sentence — what was analyzed and why)
  2. Key findings (3-5 bullets — the essential facts)
  3. Primary recommendation (bold, specific, actionable)
  4. Critical risk or caveat (the main thing that could go wrong)

Rules:

  • NEVER open the Executive Summary with methodology ("We conducted..."). Open with the context or the most important finding.
  • The recommendation must be specific enough to act on without reading the rest of the report
  • Include at least one quantified data point in the Executive Summary

Example:

We analyzed the AI code assistant market to evaluate entry opportunity. Key findings: (1) Market growing 45% annually to $15B by 2027; (2) Top 3 players hold 60% share with consolidation expected; (3) Enterprise segment underserved; (4) Regulatory uncertainty emerging. Recommendation: Pursue enterprise segment with compliance-focused positioning. Risk: AI regulation may increase development costs 20-40%.

Body Sections

Market Overview

  • What: Define the market
  • Why: Why this matters now
  • How big: Size and growth

Analysis Sections

  • Follow logical flow
  • Lead with insights, support with data
  • Use headers for scannability
  • Include trend indicators (INC/DEC/CONST)

Recommendations

  • Numbered, prioritized
  • Each MUST have four subsections: What (the specific action), Why (the business justification with data), How (concrete implementation steps), Risk (what could go wrong and mitigation)
  • Actionable and specific — "Build integrations with AWS, Azure, GCP" not "Consider expanding partnerships"

Appendix

  • Methodology notes
  • Data sources
  • Detailed tables
  • Additional analysis

Writing Principles

Clarity First

Do: Lead with the insight

Market consolidation is accelerating, with top 3 players' share growing from 45% to 60% in 18 months.

Don't: Bury the insight

According to our research, when we looked at market share data over the past 18 months, we found that the leading companies have been growing.

Pyramid Structure (Minto Pyramid)

Apply the pyramid principle at three levels:

Document level: Start with the conclusion (Executive Summary), then supporting sections, then detail.

Section level: Each section opens with its key takeaway, followed by supporting data, followed by nuances.

Paragraph level:

  • Topic sentence (the point — what the reader should remember)
  • Supporting evidence (data, quotes, analysis)
  • Implication/so what (why this matters for the reader's decision)

Anti-pattern: Never open a section with background or process description. "We analyzed 15 tools over 3 months" belongs in the appendix, not at the top of a findings section.

Active Voice

Do: "Competitors reduced prices 20%" Don't: "Prices were reduced by competitors by 20%"

Quantify Claims

Do: "Revenue grew 45% YoY to $2.3B" Don't: "Revenue grew significantly"

Hedge Appropriately

  • "Data suggests..." (uncertain)
  • "Evidence indicates..." (moderate confidence)
  • "Analysis confirms..." (high confidence)

Handling Incomplete Data

When the user provides sparse or uncertain data:

  • Present ranges, not point estimates: If the source says "$1B to $5B", write "$1B to $5B" — do not pick a midpoint
  • Explicitly flag data gaps: Add a "Data Gaps" or "Limitations" section listing what is unknown
  • Never invent market share or growth figures: If share data is not available, state "market share data is not publicly available"
  • Still follow report structure: Missing data does not excuse missing sections — adapt the section to acknowledge the gap
  • Calibrate hedging to confidence level: More hedging for uncertain claims, less for well-sourced claims

Visualization Guidelines

When to Use Charts

| Data Type | Best Visualization | |-----------|-------------------| | Comparison | Bar chart | | Trend over time | Line chart | | Composition | Pie chart (≤6 slices) | | Relationship | Scatter plot | | Distribution | Histogram | | Process/Flow | Flowchart | | Positioning | Quadrant/matrix | | Scenarios | State diagram |

Visualization Selection Rules

When selecting a visualization, follow these rules strictly:

  • Market share / composition data → Use a pie chart. If there are more than 6 slices, group the smallest into "Others".
  • Competitive positioning on two axes → Use a quadrantChart. Label both axes with descriptive endpoints (e.g., "Low Price --> High Price").
  • Scenarios / state transitions / decision paths → Use a stateDiagram-v2. Show the starting state and possible outcomes.
  • Trend data over time → Mermaid supports line charts via xychart-beta. Use `x
Compartilhar X LinkedIn