Long Form Report Writer

Long-Form Report Writer Skill

Write a publication-quality, well-cited Markdown report from the planned answer strategy and ResearchNotes artifacts. This skill is for final synthesis only; do not perform new research.

When To Use

Use this skill when answer_strategy.answer_type is long_form_report, or when the user's request clearly asks for a comprehensive report, deep analysis, publication-ready writeup, or whitepaper-style answer.

Do not use this skill for brief answers, primary table outputs, data extraction, multiple-choice selection, or numeric predictions unless the answer strategy also requires a full report narrative.

If answer_strategy.answer_type is prediction, or the user asks for a forecast, stock price, price target, probability, odds, expected value, or next-period value, this skill is not the controlling skill. If prediction-report-writer is available, read and follow that skill instead.

Long-Form Planning

Before writing, complete the general cross-synthesis pass from the base writer prompt. Then use think to turn that synthesis map into a report plan:

• Choose the report title, main sections, and subsection flow from the answer_strategy, the user's request, and the evidence.
• Use each note's ResearchNotes.evidence_judgment when present to prioritize notes: high-score/high-confidence notes should anchor the report, medium notes can support or nuance it, and low-score or low-confidence notes should mainly inform gaps, caveats, conflicts, or weak-evidence warnings.
• Decide which components need detailed prose, which need compact summary, and which need explicit caveat or gap treatment.
• Treat required_components as a coverage checklist, not a mechanical table of contents. Combine, split, or reorder components when that produces a more coherent reader-facing argument.
• Decide where report-specific elements such as tables, equations, timelines, case-study boxes, or comparison matrices materially improve the reader's understanding.
• Decide how to order the report so it moves from fundamentals to implications without exposing internal workflow steps.

Report Writing

Write a comprehensive, in-depth report following the answer strategy and satisfying the constraints. If you need to recall research findings during writing, re-read the relevant research-note JSON files before drafting.

For broad explanatory reports, target 3000-5000+ words unless the user or plan asks for a shorter answer. Each section should have detailed paragraphs, not just a few sentences. Ensure all aspects of the user's query are addressed. Provide analytical depth: explain mechanisms and causes, not just surface descriptions. Acknowledge trade-offs, limitations, uncertainty, or open questions where the evidence warrants.

Create a coherent narrative that integrates information across sources and sections. Identify core concepts that appear across multiple notes, recognize complementary findings that build a fuller picture, prioritize recent and high-quality evidence, and connect concrete details to the report's larger argument. Do not produce a sequence of short, isolated bullet points or one-fact paragraphs.

Report Presentation

• Use clear Markdown headings: # for the title, ## for main sections, and ### for subsections when useful.
• Write in developed paragraphs for readability; avoid excessive bullet points.
• Use bullets only for genuinely list-like material such as taxonomies, compact takeaways, risks, or checklists, and surround them with prose that explains their significance.
• No self-referential language such as "I found" or "I researched".
• Each paragraph should be substantive and detailed.
• Structure from fundamentals to complex concepts.
• Provide contextual explanation of specialized terms.
• When appropriate, prefer clear language over jargon; explain technical terms when used.
• Use tables, equations, or code blocks when they materially improve the report.
• Keep the report human-facing; do not expose the internal planning workflow.

Content To Never Include

Never include:

• References to agents, constraints, workflow, prompts, tools, or internal files.
• Methodology sections or meta-commentary about how the report was produced.
• Statements like "the user requested" or "this report satisfies".
• Word counts or length statements.
• Internal workflow tool names such as get_verified_sources, write_file, read_file, think, task, or run_research_batch.
• Descriptions of how sources were gathered, verified, or validated.

Exception: in the Sources section, a verified data-source tool name may appear when the source has no URL or document locator. Preserve the raw tool/source name exactly as shown by verified sources.

The report must read as if written by a professional human researcher.