Deep Research Writing Guide

Deep Research Writing Guide

Comprehensive methodology for creating research-intensive, long-form content. Follow ALL rules exactly.

---

RESEARCH METHODOLOGY (DO THIS FIRST)

Before writing a single word, conduct EXTENSIVE web research. This is a deep research guide, not a surface-level blog. The quality of the article depends entirely on the depth of research.

Research process:

1. Wide discovery: Run at least 15-20 distinct web searches across different angles of the topic. Cover market data, company-specific data, analyst reports, industry surveys, technical documentation, academic papers, and recent news.
2. Identify key threads: From broad results, identify the 3-5 most important data threads.
3. Deep dives: Run targeted searches on each key thread. Get specific numbers: exact percentages, dollar amounts, dates, company names, source attribution with URLs.
4. Counter-narrative search: Explicitly search for data that CONTRADICTS your thesis. Include credible counter-arguments.
5. Verify and source: Every statistic, valuation, revenue figure, and market claim must have an attributable source with a URL. No placeholder data.
6. Collect URLs: Build a reference list of ALL URLs found during research. You will embed these as inline hyperlinks throughout the article. Minimum 30 hyperlinks for deep guides, 10 for shorter articles.

The article MUST be at least 10,000 words. Deep guides target 12,000-15,000 words. This is non-negotiable. If the draft is under 10,000 words, expand existing sections with more depth, examples, trade-off analysis, and implementation detail until you reach the minimum.

---

OUTPUT FORMAT

Generate a Python script that writes the article to /home/user/output/article.md.

CRITICAL LENGTH REQUIREMENT: The article MUST be at least 10,000 words. To achieve this:

1. Structure code with 12-16 section functions, each returning 800-1,200 words of content
2. Each function appends its section to the file using mode "a"
3. MAXIMIZE the amount of prose in each function. Do NOT summarize or abbreviate. Write FULL paragraphs with detailed analysis, examples, trade-offs, and implementation specifics
4. The CONCISENESS rule from the system prompt does NOT apply to this task. This is a LONG-FORM writing task. MORE content is BETTER. Fill every section with depth
5. After writing all sections, read back the file and count words. If under 10,000, append additional depth sections

For charts: ticks = chr(96) * 3 then content += ticks + "chart" + chr(10) + json_string + chr(10) + ticks For diagrams: same pattern with "mermaid" instead of "chart"

Print JSON summary at end: title, word_count, hyperlinks, charts, diagrams.

Pre-installed: pandas, numpy, matplotlib, scipy, scikit-learn. Install extras with subprocess.

---

1. EM DASHES ARE BANNED (ZERO TOLERANCE)

NEVER use em dashes (the long dash character) anywhere. Use alternatives:

---

2. BOLD FORMATTING (CRITICAL)

Bold only keywords and key phrases (1-5 words max), NEVER entire sentences.

Bold is for scanability. 3-6 bold elements per paragraph. Each bold element: 1-5 words.

What to bold:

• Statistics/numbers: "attracted 145,000 GitHub stars in three weeks"
• Product/company names: "Platforms like Acme Corp provide..."
• Technical terms: "The sandbox configuration controls..."
• Key phrases in lists: "- Monitors channels for incoming commands"
• Pricing: "Pro plan costs $49.99/month"

What NOT to bold: entire sentences, clauses longer than 6 words, explanatory text, links.

---

3. INLINE HYPERLINKS (HARD FAIL)

Minimum 10 hyperlinks per article. Deep guides need 30-80+. Zero hyperlinks = unpublishable.

Every statistic, pricing claim, or factual assertion needs a source link inline. Company/product names should link to their official site on first mention.

Format: [descriptive anchor text](https://url) - never "click here" or raw URLs.

Rules:

1. Link on first mention of a company/product (not every mention)
2. Max 1 link per statement
3. Use descriptive anchor text
4. Precede source links with -: claim text - [Source](url)
5. Verify URLs are real before including. If unsure, use the homepage

---

4. ARTICLE STRUCTURE

NEVER include an H1 title in the body. The title is provided separately.

Required sections:

1. Subtitle (one-line value prop, bolded, first element)
2. Opening Hook (compelling statistic or fact, bolded)
3. Problem Statement (why the reader should care)
4. What This Guide Covers (set expectations)
5. Table of Contents (for articles over 3,000 words)
6. Main Content Sections (numbered for clarity)
7. Comparison Tables (required for alternatives/vs articles)
8. Conclusion (summary with clear decision framework)
9. Date Disclaimer at end

Section lengths:

• Introduction: 200-400 words
• Major sections: 500-1,500 words each
• Product descriptions: 200-400 words
• Conclusion: 200-400 words
• Total for comprehensive guides: 10,000-15,000 words

---

5. NARRATIVE DENSITY (HARD FAIL RULES)

These are non-negotiable. Violation = unacceptable article. EVERY section MUST start with substantial prose.

1. For every ## and ### section, write at least 2 full paragraphs (120+ words total, roughly 8-10 sentences) BEFORE any list, bullet point, or numbered item. NO EXCEPTIONS. If a section starts with a list, rewrite it with explanatory prose first.
2. After any list with 3+ items, add at least 1 paragraph (80+ words) before the next heading
3. Never place two list blocks back-to-back without narrative prose between them
4. Max 5 items per list. If you need more, split into sub-sections
5. List lines must stay at or below 30% of non-empty lines in each major section
6. Every major section must answer both: "Why this matters" and "How to apply this" in prose

Section writing formula:

1. Context paragraph (what and why now)
2. Explanatory paragraph (trade-offs, implications, mechanics)
3. Optional short list (for structure/scanability)
4. Interpretation paragraph (what the list means in practice)
5. Transition paragraph (connection to next section)

---

6. REAL DATA ONLY

Never use placeholder data. Every claim must be:

• Specific: Not "many users" but "145,000 GitHub stars"
• Sourced: Include links to sources
• Current: Use recent data
• Verifiable: Reader should be able to confirm

HYPE FILTER: Do NOT blindly repeat self-reported startup metrics. Only include claims verified by credible third parties (SEC filings, reputable journalists, earnings calls). Founders claiming revenue on podcasts or social media is NOT credible.

---

7. FIRST-PRINCIPLES ANALYSIS (CRITICAL)

All analysis must be built from first principles, not consensus narratives.

Process:

1. Start with the structural question, not the surface question
2. Identify actual inputs and outputs (what does the market buy?)
3. Apply analogies from previous tech shifts, but test them
4. Layer data on top of the structural argument
5. Pressure-test your own conclusion

BAD: "AI labs are gaining share and startups should focus on vertical AI." GOOD: "Intelligence is becoming a commodity input. When inputs become cheap, businesses that use those inputs to deliver valuable outputs flourish. The opportunity is not in competing on intelligence but in combining cheap intelligence with domain expertise to deliver outcomes."

---

8. PRICING REQUIREMENTS

Always include actual pricing, never "contact sales" alone.

| Plan | Monthly Cost | Credits |
|------|-------------|---------|
| Free | $0 | 400 |
| Pro | **$49.99** | 5,000 |
| Business | **$299.99** | 30,000 |
| Enterprise | Custom | Unlimited |

---

9. TABLES

Use for pricing comparisons, feature comparisons, plan breakdowns, statistics summaries.

Rules:

• Bold key data points (prices, names)
• Left-align text, right-align numbers
• Include units ($/mo, credits)

---

10. SOURCE CITATIONS

Use inline markdown links with descriptive anchor text.

Prioritize: official docs, company pricing pages, industry publications (Gartner, Forrester), reputable tech news (The Register, Ars Technica), expert blogs.

Avoid: random Medium posts, outdated articles, marketing fluff.

---

11. HEADERS

## Major Section (H2) - numbered in listicles
### Subsection (H3)
#### Minor heading (H4) - use sparingly

Headers should be descriptive and scannable. Include numbers for major sections. Do NOT bold headers (they are already emphasized).

---

12. TONE AND VOICE

• Be specific, not vague: "73% of SMBs reported gains" not "Many businesses see improvements"
• Be direct, not hedging: "This is an autonomous agent" not "This might potentially be considered..."
• Be practical, not marketing: "Here's what it costs" with real numbers, not "Unlock the power of AI"
• Acknowledge trade-offs: Every product has limitations. State them.
• Subtly intelligent humor is welcome. Never sensationalist. Never "happy flappy."
• Grammatically correct, coherent, to the point

---

13. CHARTS AND DATA VISUALIZATION (MANDATORY)

Any section with market data, pricing comparisons, growth metrics, or quantitative trends MUST include charts EMBEDDED IN THE MARKDOWN using the exact syntax below. Charts are NOT described in prose. They are LITERAL fenced code blocks with language identifier "chart" that get rendered by the frontend. You MUST include at least one chart in every article.

EXACT chart syntax (copy this pattern literally into the markdown string):

**Chart types**:
- `"line"`: Time series, trends, continuous data (use when x-axis is time)
- `"bar"`: Discrete comparisons, rankings, snapshots
- `"grouped-bar"`: Multiple data series on same x-axis

**Rules**:
- NEVER specify colors (design system applies them automatically)
- Every chart MUST have a `source` field with real attribution
- Max 3 data series per chart, max 8 data points
- Use a MIX of chart types across the article
- Title states what the chart shows. Subtitle adds context (time period, methodology)

---

### 14. DIAGRAMS (MERMAID)

Use diagrams for architecture, process flows, comparisons, hierarchies. At least 1 diagram per deep guide (10,000+ words).

**Diagram syntax**:

````markdown

**Supported types** (flowcharts ONLY):
- `graph TD` (top-down): hierarchies, stacks, process flows
- `graph LR` (left-right): horizontal processes, timelines, pipelines
- `graph TB` with `subgraph`: grouping nodes into categories

**Rules**:
- DO NOT add style, classDef, class, or color directives (component themes automatically)
- Use ` ["Text"]` for node labels with quotes
- Use `-->` for solid arrows, `-.->` for dashed arrows
- Max 15 nodes per diagram
- Labels under 40 characters per line

---

### 15. ARTICLE TYPES

**"Top X Alternatives"**: 10,000-15,000 words, 200-400 words per alternative, pricing table + comparison table required.

**"How To" Guides**: 3,000-8,000 words, step-by-step numbered instructions, code examples per step.

**"Comparison" (X vs Y)**: 5,000-10,000 words, side-by-side feature table, pricing comparison, clear winner statements.

**"State of X in [Year]"**: 10,000-20,000 words, multi-source statistics, predictions section, industry breakdown.

---

### 16. LENGTH RECOVERY

If draft is below target word count:
1. Freeze the outline after first draft
2. Expand EXISTING sections (add context, mechanisms, examples, trade-offs)
3. Keep narrative style consistent start to finish
4. Do NOT append new top-level sections to pad word count
5. Do NOT add list-only appendices
6. Preferred: add case examples, failure mode analysis, implementation walkthroughs, comparative analysis paragraphs

---

### 17. QUALITY CHECKLIST

Before finalizing, verify:
- [ ] No em dashes anywhere
- [ ] Bold formatting: short keywords only (1-5 words)
- [ ] Minimum 10 inline hyperlinks (deep guides: 30-80+)
- [ ] All claims have source links
- [ ] Tables used for comparisons
- [ ] Code blocks have language specified
- [ ] Numbered headers for major sections
- [ ] Opening hook with bold stat
- [ ] Every section has introductory prose, not just bullets
- [ ] 2+ paragraphs before first list in each section
- [ ] No back-to-back lists without prose between them
- [ ] List density <= 30% per section
- [ ] Max 5 items per list
- [ ] First-principles analysis (structural reasoning, not consensus)
- [ ] Charts for data-heavy sections
- [ ] At least 1 mermaid diagram in deep guides
- [ ] Mix of visualization types
- [ ] Date disclaimer at end

---

*This methodology produces research-intensive, authoritative long-form content that ranks well and builds reader trust.*