Anycap Deepresearch

AnyCap Deep Research

Read this entire file before starting. It defines the multi-source research workflow from planning through synthesis.

Conduct thorough, multi-source research on any topic. Gather information broadly, verify claims rigorously, and synthesize findings into a polished, well-sourced report.

Think deeply. Search broadly. Verify everything. Deliver clearly.

Before You Start

Read all five reference files before taking any action. Understanding the full process prevents wasted effort and ensures thorough research.

1. Read this file (SKILL.md) for the overview and principles 2. Read each reference in order:

• 01-plan.md
• 02-gather.md
• 03-analyze.md
• 04-synthesize.md
• 05-deliver.md

3. Then begin Phase 1: Plan

For detailed CLI command usage (flags, output formats, jq patterns), refer to the anycap-cli skill and its references.

Prerequisites

• anycap CLI installed and authenticated (anycap status to verify)
• A local working directory for intermediate files

When to Use This Skill

• Deep research, research report, deep dive on any topic
• Competitive analysis, market research, technology comparison
• Literature review or state-of-the-art survey
• Investigative research requiring cross-referencing multiple sources
• Any task where a single search is insufficient

Research Process

Follow the research process below. User clarification is mandatory -- do not skip it.

graph LR
    A["Preliminary Search<br/>(optional)"] --> B[Clarify with User]
    B --> C[Plan]
    C --> D[Gather]
    D --> E[Analyze]
    E --> F[Synthesize]
    F --> G[Deliver]
    E -->|gaps found| D

The process starts with an optional preliminary search to build context, followed by a mandatory clarification with the user, then autonomous execution.

Each phase has detailed guidance in the references:

1. [Plan](references/01-plan.md) -- Preliminary search (optional), clarify with user (mandatory), design search strategy, set up workspace 2. [Gather](references/02-gather.md) -- Execute searches, crawl pages, download and save all raw material 3. [Analyze](references/03-analyze.md) -- Cross-verify claims, assess source quality, identify gaps 4. [Synthesize](references/04-synthesize.md) -- Write the report with proper sourcing and illustrations 5. [Deliver](references/05-deliver.md) -- Save to Drive, publish as web page, or both

Human-in-the-Loop

This skill involves the user at key decision points:

1. Before research begins -- Clarify the research question, confirm sub-questions, agree on delivery format, and ask whether image generation is permitted. See 01-plan.md. 2. During synthesis -- Review all downloaded and generated images yourself (via anycap actions image-read) before including them in the report. See 04-synthesize.md.

Do not skip the initial clarification. A 2-minute conversation with the user can save an hour of misguided research.

Once research begins (Phase 2 onward), work autonomously. Do not interrupt the user with questions during gathering, analysis, or synthesis. Make your best judgment based on the preferences established in Phase 1. If you encounter ambiguity, note it in your research journal and resolve it with the best available evidence.

Core Principles

Be thorough, not frugal. Use as many searches and crawls as needed to produce a comprehensive report. Breadth and depth of research determine report quality.

Save everything. Write intermediate results (search outputs, crawled pages, grounding responses, notes) to local files. These are your evidence base for cross-verification and sourcing.

Verify, do not assume. Cross-check important claims across multiple independent sources. When sources conflict, investigate further rather than picking one.

Search in parallel. When sub-questions are independent, run multiple searches concurrently rather than sequentially. This produces results faster and gives you more material to cross-reference.

Prefer AI Grounded search for complex questions. Grounding search (--prompt) synthesizes across multiple sources and provides citations. Use it generously for questions that benefit from multi-source synthesis. Use general search (--query) for finding specific pages and data points.

Use mermaid for diagrams. When the report needs architecture diagrams, flow charts, timelines, or comparisons, use mermaid syntax in markdown. Both Drive and Page render mermaid natively. Always verify mermaid diagrams render correctly before including them in the final report (see 04-synthesize.md).

Prefer original images. When a source provides relevant images, diagrams, or screenshots, download and use the originals. Only generate images when you need to explain a concept, aggregate data into a visualization, or express information more clearly than the source material. Generated images must not misrepresent or deviate from the source material.

Quick Reference

Phase 1: Plan

This phase has three steps: preliminary search (optional), user clarification (mandatory), and search strategy design.

Step 1: Preliminary Search (Optional)

If the topic is unfamiliar or complex, run a few quick searches first to build context. This helps you ask better clarification questions:

# Quick scan to understand the landscape
anycap search --query "topic" --no-crawl --max-results 5

# Or get a grounded overview
anycap search --prompt "What is [topic] and what are the key aspects?"

Skip this step if the topic is straightforward or you already have enough context to ask good questions.

Step 2: Clarify with the User (Mandatory)

This step is not optional. Do not assume you understand the user's intent -- ask.

Present your understanding of the topic (informed by the preliminary search if you did one) and ask the user to refine it:

1. Scope and focus -- "Here are the sub-questions I plan to investigate: [list]. Are there angles you want me to add, remove, or prioritize?" 2. Delivery format -- "How would you like the report delivered? Options: local Markdown file, shareable Drive link, published web page, or a combination." 3. Image generation -- "May I generate illustrations (diagrams, comparisons) where they would aid understanding? Or should I only use original images from sources?" 4. Depth vs breadth -- If the topic is large, ask whether the user wants broad coverage or a deep dive on specific aspects.

Wait for the user's response. You may need multiple rounds of clarification -- use your judgment to decide when you have enough information to proceed. If the user's initial request is already very specific and detailed, one round may suffice. If the topic is broad or ambiguous, ask follow-up questions until the scope is clear.

Exit clarification when:

• You have a clear, confirmed list of sub-questions to investigate
• You know the user's preferred delivery format (or have a reasonable default)
• Any ambiguity in the original request has been resolved

Do not over-clarify. Once the research direction is clear, start working.

Step 3: Decompose and Plan

Break the user's request into sub-questions. A good decomposition produces 3-10 sub-questions that, when answered together, form a comprehensive response.

Example: "Research the current state of WebAssembly outside the browser"

• What server-side WASM runtimes exist and how do they compare?
• How is WASM used in edge computing (Cloudflare, Fastly, etc.)?
• What is the WASM Component Model and what is its status?
• What production use cases exist for WASM as a plugin system?
• What are the performance characteristics vs native code?
• What languages have mature WASM compilation support?
• What are the current limitations and open challenges?

Design Search Strategy

For each sub-question, decide on your approach:

Plan to search broadly. Multiple searches per sub-question is normal -- start wide, then narrow.

Prefer grounding search for complex questions. --prompt mode is your most powerful research tool -- it synthesizes across multiple web sources and provides structured citations. Use it liberally for definitional questions, comparisons, and state-of-the-art surveys.

Plan for parallelism. Identify sub-questions that are independent of each other and can be researched simultaneously. If your agent supports parallel tool calls, batch independent searches together to save time.

Set Up Workspace

Create a local directory structure for intermediate files:

research-{topic}/
  notes.md            # Running notes, observations, hypotheses
  sources/            # Saved search results and crawled pages
  assets/             # Downloaded images and generated illustrations

mkdir -p research-{topic}/sources research-{topic}/assets

The notes file is your research journal. Update it continuously as you gather and analyze information.

Record User Preferences

At the top of notes.md, record the user's answers from the clarification step:

## Research Preferences
- Delivery: [local / drive / page / drive+page]
- Image generation: [allowed / originals only]
- Focus: [broad coverage / deep dive on X, Y]
- User notes: [any specific guidance from the user]

Refer back to these preferences throughout the research process.

Phase 2: Gather

Execute your search plan. Save every result to a local file for later cross-verification.

Search Strategies

Broad Discovery -- Map the Landscape

Start with wide searches to understand the information space:

# Fast scan: titles and URLs only
anycap search --query "topic overview" --no-crawl --max-results 10 \
  | tee research-topic/sources/scan-overview.json

# Recent developments
anycap search --query "topic" --time-range month --no-crawl --max-results 10 \
  | tee research-topic/sources/scan-recent.json

# Domain-specific authoritative sources
anycap search --query "topic" --include arxiv.org --include github.com --no-crawl \
  | tee research-topic/sources/scan-academic.json

Deep Reading -- Extract Substance

For relevant results, get full page content:

# Full content search (results include crawled page content)
anycap search --query "specific aspect of topic" --max-results 5 \
  | tee research-topic/sources/search-aspect-1.json

# Read a specific important page
anycap crawl https://important-source.com/article \
  | tee research-topic/sources/crawl-source-name.json

# Extract just the markdown for reading
anycap crawl https://docs.example.com/spec | jq -r '.data.markdown' \
  > research-topic/sources/spec-content.md

AI Grounded Answers -- Fill Knowledge Gaps

Use grounding search for complex questions that benefit from synthesis:

# Get a grounded answer with citations
anycap search --prompt "How does X compare to Y in terms of Z?" \
  | tee research-topic/sources/grounding-comparison.json

# Extract the synthesized answer
anycap search --prompt "What are the key limitations of X?" \
  | jq -r '.data.content' \
  | tee research-topic/sources/grounding-limitations.md

# Save the sources for cross-verification
anycap search --prompt "What are the key limitations of X?" \
  | jq -r '.data.search_metadata.sources[] | "\(.title): \(.uri)"' \
  >> research-topic/notes.md

Time-Bounded Research

For researching events or developments in a specific time period:

# Exact date range
anycap search --query "topic" --after 2025-01-01 --before 2025-12-31

# Relative time window
anycap search --query "topic latest news" --time-range week

Domain Filtering

Focus on authoritative sources:

# Only academic and official sources
anycap search --query "topic" --include arxiv.org --include github.com --include ieee.org

# Exclude low-quality sources
anycap search --query "topic" --exclude pinterest.com --exclude quora.com

Downloading Source Images

When a source contains important images (diagrams, charts, screenshots), download the originals:

# Download an image from a source
curl -o research-topic/assets/architecture-diagram.png "https://example.com/diagram.png"

Prefer original images over generated ones. Record the source URL alongside each downloaded image in your notes.

Analyzing Video Content

When research sources include video content (conference talks, demos, tutorials), use AnyCap to analyze them:

# Analyze a video for key insights
anycap actions video-read --url https://example.com/talk.mp4 \
  --instruction "Summarize the key points about [topic]" \
  | tee research-topic/sources/video-talk-summary.json

Video analysis is especially useful for conference presentations, product demos, and technical walkthroughs that may contain information not available in written form.

Using Other Tools and Skills

Deep research is not limited to web search and crawl. Actively use any available tools and skills to gather and extract information:

• PDF documents -- Download PDFs and use your PDF reading capability to extract content from research papers, whitepapers, and technical specifications.
• Image understanding -- Use anycap actions image-read to extract text from screenshots, analyze diagrams, or read infographics found during research.
• Audio analysis -- Use anycap actions audio-read to transcribe and analyze podcast episodes or audio recordings relevant to the topic.
• File downloads -- Download data files, spreadsheets, or archives when they contain relevant primary data.
• Other skills -- If you have access to other skills (e.g., for specific platforms, APIs, or data sources), use them. The goal is comprehensive information gathering through every available channel.

The key principle: use every tool at your disposal to produce the most thorough and well-sourced report possible.

Saving Intermediate Results

Save everything. Every search output, every crawled page, every grounding response should be written to a file. This serves three purposes:

1. Evidence base -- you can re-read sources without re-crawling 2. Cross-verification -- compare claims across saved sources 3. Sourcing -- build the final sources list from your saved files

Verifying Grounding Search Sources

When using --prompt (grounding search), the response includes search_metadata.sources with the actual URLs the AI used. Always extract and record these source URLs -- they are your traceable citations:

# Save the full grounding response
anycap search --prompt "What is X?" | tee research-topic/sources/grounding-X.json

# Extract the actual source URLs for your sources list
cat research-topic/sources/grounding-X.json \
  | jq -r '.data.search_metadata.sources[] | "[\(.index)] \(.title): \(.uri)"' \
  >> research-topic/notes.md

Do not cite a grounding search as "Grounding search: topic" in your final report. Instead, trace the claim back to the specific source URLs provided in search_metadata.sources and cite those URLs directly. If a grounding response lacks source URLs (search_metadata is null), treat the information as unverified and corroborate it with a separate search.

Update notes.md continuously with:

• Key findings from each search
• Interesting URLs to crawl later
• Contradictions or open questions
• Source quality assessments

## Notes

### Sub-question 1: Server-side WASM runtimes
- Found 3 major runtimes: Wasmtime, Wasmer, WasmEdge
- Source: scan-overview.json result #2 (bytecodealliance.org)
- CONFLICTING: Wasmer claims faster startup than Wasmtime, but benchmarks from source X show otherwise
- TODO: Find independent benchmark comparison

### Sub-question 2: Edge computing
- Cloudflare Workers uses V8 isolates, not pure WASM -- need to clarify
- Source: crawl-cloudflare-blog.json
- TODO: Check Fastly Compute@Edge for comparison

Phase 3: Analyze

After gathering raw material, pause and think critically before writing.

Cross-Verification

Cross-verification is the most important step in producing a trustworthy report. A claim that appears in only one source is a lead; a claim confirmed by multiple independent sources is a finding.

Verification Strategies

Triangulation -- verify key claims across 3+ sources:

For any important claim (numbers, dates, comparisons, technical facts), check whether multiple independent sources agree. Use your saved intermediate files:

# Re-read saved sources without re-crawling
cat research-topic/sources/search-runtimes.json | jq -r '.data.results[] | "\(.title): \(.url)"'
cat research-topic/sources/grounding-comparison.md

If a claim appears in only one source, either:

• Search specifically for corroborating evidence
• Search for counter-evidence
• Note it as "single-source, unverified" in the report

# Targeted verification search
anycap search --query "specific claim to verify" --max-results 5 \
  | tee research-topic/sources/verify-claim-X.json

# Check the original source directly
anycap crawl https://primary-source.com/data \
  | tee research-topic/sources/verify-primary.json

Source comparison -- identify conflicts:

When sources disagree, investigate:

1. Which source is more authoritative? (primary > secondary, official > blog) 2. Which is more recent? (newer data may supersede older claims) 3. Are they measuring different things? (different methodologies, different definitions) 4. Is there a third source that resolves the conflict?

Record conflicts in your notes with explicit references to the saved files:

### Conflict: WASM startup time
- Source A (wasmtime blog, sources/crawl-wasmtime.json): "cold start under 1ms"
- Source B (benchmark study, sources/crawl-benchmark.json): "average 3.2ms cold start"
- Resolution: Source A measures module instantiation only; Source B includes compilation.
  Both are correct for different definitions of "cold start".

Temporal verification -- check freshness:

Information decays. A benchmark from 2023 may be irrelevant for a runtime that had a major release in 2025.

# Search for the most recent data on a specific point
anycap search --query "topic benchmark 2025 2026" --time-range year

Source Quality Assessment

Rate each source as you analyze:

Prefer primary and authoritative sources. Use secondary sources for leads, then trace back to the primary source.

Gap Analysis

After analyzing your gathered material, identify what is still missing:

1. Which sub-questions from your plan remain unanswered? 2. Which claims lack cross-verification? 3. Are there perspectives or counterarguments you have not explored? 4. Is any data outdated and needs a fresh search?

For each gap, go back to Phase 2 with targeted searches. This loop (Gather -> Analyze -> Gather) is normal and expected. A thorough report usually requires 2-3 iterations.

When to Stop Searching

The agent decides autonomously when enough material has been gathered. Stop the Gather-Analyze loop when:

• All sub-questions have at least one verified answer from a primary or authoritative source
• Key claims are cross-verified across 2+ independent sources
• New searches return diminishing results -- you are seeing the same sources and claims you already have
• Remaining gaps are acknowledged -- some questions may not have publicly available answers; note them as limitations rather than searching indefinitely

Do not stop early just because you have some results. Do not search forever chasing perfection. Use your judgment: a thorough report with noted limitations is better than an incomplete report or an infinite search loop.

Update Your Notes

Before moving to synthesis, consolidate your analysis in notes.md:

• List all verified findings with source references
• List all unresolved conflicts with context
• List all gaps that could not be filled
• Draft a preliminary outline based on what you have found

Phase 4: Synthesize

Write the report from your verified findings. This is where raw research becomes a coherent narrative.

Report Structure

# [Research Topic]

> Research conducted on [date]. Sources verified as of this date.

## Executive Summary

[2-3 paragraphs: what was researched, key findings, main conclusions]

## Background

[Context the reader needs to understand the topic]

## Findings

### [Sub-topic 1]

[Analysis with inline source references]

### [Sub-topic 2]

[Analysis with inline source references]

...

## Analysis

[Cross-cutting insights, comparisons, patterns across sub-topics]

## Limitations

[What this research does not cover, unresolved questions, data gaps]

## Conclusions

[Key takeaways and recommendations]

## Sources

1. [Title](URL) -- what this source contributed to the report
2. [Title](URL) -- what this source contributed
...

For long reports, always include the Sources section -- it gives readers a consolidated bibliography to browse. When using footnote-style references in the body (e.g., [[1]](URL)), the Sources section maps each number to its full title and URL.

Writing Guidelines

Source everything with hyperlinks. Every claim must be traceable to its source via a clickable link. Two styles are acceptable and can be mixed:

Inline links -- link the relevant phrase directly to the source:

Cloudflare Workers uses V8 isolates rather than traditional containers for workload isolation.

Footnote links -- use numbered references with hyperlinks. Each footnote number in the body must be a clickable link to the source URL:

Cloudflare Workers uses V8 isolates rather than traditional containers [[1]](https://blog.cloudflare.com/workers-architecture) for workload isolation.

For long reports, use footnotes with a Sources section at the end so readers can browse all references in one place. For shorter pieces, inline links are cleaner. Both styles can coexist in the same report.

Never use plain-text footnote numbers like [1] without a hyperlink -- every reference must be clickable where it appears.

Present multiple perspectives. When sources disagree and the conflict could not be resolved, present both views and explain the disagreement. Do not silently pick a side.

Distinguish facts from analysis. Make it clear what is reported fact ("Source X states...") versus your interpretation ("This suggests that...").

Use tables and lists for comparisons. Structured data is easier to scan than prose. Use tables for feature comparisons, timelines, or multi-source data.

Include specific data. Numbers, dates, version numbers, quotes -- specifics make a report credible. Vague claims ("many companies use X") are weak; specific claims ("as of 2026, Cloudflare Workers, Fastly Compute, and Vercel Edge Functions support WASM runtimes") are strong.

Illustrations

Use Mermaid for Diagrams

When the report needs architecture diagrams, flow charts, timelines, sequence diagrams, or comparison structures, use mermaid syntax in markdown code blocks:

````markdown

graph LR
    A[Component A] --> B[Component B]
    B --> C[Component C]

````

Both Drive and Page render mermaid natively. Prefer mermaid over ASCII art -- it produces clean, readable diagrams.

Good uses for mermaid:

• Architecture and system diagrams
• Process flows and decision trees
• Timelines and sequence diagrams
• Comparison matrices (use tables for simple ones, mermaid for complex relationships)

Verify Mermaid Before Publishing

Mermaid diagrams can silently fail to render due to syntax errors, unsupported features, or edge cases in node labels. Always verify mermaid diagrams render correctly before including them in the final report.

Verification workflow:

1. Write your mermaid blocks in the report markdown. 2. Deploy a test page with just the report (or the mermaid blocks) to check rendering:

# Quick test deploy
anycap page deploy research-topic/report.md --new --name "mermaid-test" --publish

3. Open the page URL and visually confirm each diagram renders correctly. 4. Fix any syntax issues and redeploy until all diagrams look right. 5. Delete the test page after verification (or reuse the site for the final deploy).

Common mermaid pitfalls:

• Special characters in node labels (use quotes: A["Label with (parens)"])
• Long labels that overflow (keep labels concise)
• Unsupported diagram types (stick to graph, flowchart, sequenceDiagram, gantt, pie, mindmap)
• Missing semicolons or arrows in sequence diagrams

Prefer Original Images

When a source provides a diagram, chart, screenshot, or photo that explains a concept, use the original. Download it during the Gather phase and reference it in the report:

![Architecture diagram from the official documentation](research-topic/assets/architecture-diagram.png)
*Source: [Official Docs](https://example.com/docs) [[3]](https://example.com/docs)*

Always attribute the source when using original images.

Review Every Image Before Including It

Before adding any image (downloaded or generated) to the report, review it yourself using image understanding:

# Check a downloaded image for relevance and readability
anycap actions image-read --file research-topic/assets/architecture-diagram.png \
  --instruction "Describe what this diagram shows. Is it clear and relevant to [topic]?"

# Verify a generated illustration is accurate
anycap actions image-read --file research-topic/assets/comparison-chart.png \
  --instruction "Does this chart accurately represent [the data I intended]?"

Do not include images you have not reviewed. A blurry screenshot, an irrelevant diagram, or an inaccurate generated chart damages the report's credibility.

When to Generate Images

Generate images only when:

• Aggregating information -- combining data from multiple sources into a single comparison chart or timeline that does not exist in any source
• Explaining a concept -- creating a diagram to clarify a complex idea that no source illustrates well
• Improving expression -- a visual would communicate the finding more effectively than text alone

Generated images must faithfully represent the underlying data and analysis. Do not generate images that embellish, exaggerate, or misrepresent the source material.

# Generate an explanatory diagram
anycap image generate \
  --prompt "clean comparison diagram showing [concept based on verified data]" \
  --model seedream-5 -o research-topic/assets/comparison-diagram.png

Sharing Images in Reports

For multi-file reports (markdown + images), use Page deployment with relative paths. This is the most reliable approach -- all assets are served from the same site, no embedding issues.

Organize your report directory with images alongside the markdown:

research-topic/
  report.md              # references images as ![](assets/diagram.png)
  assets/
    diagram.png
    comparison-chart.png

Deploy the entire directory:

anycap page deploy research-topic/ --new --name "Research: Topic" --publish

All relative image paths (assets/diagram.png) resolve correctly within the deployed site.

Do not embed Drive share links as images inside Drive-shared markdown files. Drive share links are standalone -- when one markdown file references another Drive share URL as an embedded image, the nested link may fail to load (especially with access controls). For single-file sharing (a PDF, a standalone image), Drive works fine. For anything with embedded images or multiple linked files, use Page.

Phase 5: Deliver

Choose a delivery format based on the user's needs. You can combine multiple options.

Option A: Local Markdown File (Default)

Write the report to a local file. This is the simplest path and always appropriate.

# The report is already written as a local file during synthesis
# e.g., research-topic/report.md

Present the file path to the user.

Option B: Drive Upload (Single-File Sharing)

Drive is best for sharing standalone files -- a single PDF, a data export, or individual images. Upload and share:

# Upload the report
anycap drive upload research-topic/report.pdf --parent-path /research

# Generate a shareable link
anycap drive share --src-path /research/report.pdf --expires 30d

Present the share URL to the user.

Drive limitation: do not embed Drive share links inside Drive-shared markdown. When a Drive-hosted markdown file references images via other Drive share URLs, the nested links may fail to load (especially with access controls). For reports with embedded images, diagrams, or mermaid charts, use Page (Option C) instead.

Option C: Published Web Page (Polished Presentation)

For a professional presentation, convert the report to HTML and publish:

# Write the report as an HTML file with clean typography
# (wrap the markdown content in a minimal HTML template)

# Deploy as a published page
anycap page deploy research-topic/report.html --new --name "Research: Topic Name" --publish

The output includes a page_url that anyone can visit.

HTML Template

When publishing as a page, wrap the report in a clean HTML template:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>[Report Title]</title>
  <style>
    body {
      max-width: 800px;
      margin: 2rem auto;
      padding: 0 1.5rem;
      font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, sans-serif;
      line-height: 1.7;
      color: #1c1f17;
    }
    h1 { font-size: 2rem; margin-top: 2rem; }
    h2 { font-size: 1.5rem; margin-top: 2rem; border-bottom: 1px solid #d8dcd0; padding-bottom: 0.3rem; }
    h3 { font-size: 1.2rem; margin-top: 1.5rem; }
    blockquote { border-left: 3px solid #6b7d3a; padding-left: 1rem; color: #4d5145; }
    table { border-collapse: collapse; width: 100%; margin: 1rem 0; }
    th, td { border: 1px solid #d8dcd0; padding: 0.5rem 0.75rem; text-align: left; }
    th { background: #f4f6f0; }
    img { max-width: 100%; height: auto; border-radius: 4px; }
    a { color: #6b7d3a; }
    code { background: #f4f6f0; padding: 0.15rem 0.3rem; border-radius: 3px; font-size: 0.9em; }
    .source-note { font-size: 0.85rem; color: #6b7068; font-style: italic; }
  </style>
</head>
<body>
  <!-- Convert your markdown report to HTML here -->
</body>
</html>

Option D: Both Drive and Page

Upload the raw Markdown to Drive (for download and reference) and publish the full report directory as a Page (for reading and sharing).

# Drive: raw markdown for reference/download
anycap drive upload research-topic/report.md --parent-path /research
anycap drive share --src-path /research/report.md --expires 30d

# Page: full report with images and mermaid rendering
anycap page deploy research-topic/ --new --name "Research: Topic Name" --publish

Present both the Drive link (for downloading the raw markdown) and the Page URL (for reading the rendered report with images and diagrams) to the user.

Choosing a Delivery Format

If the user does not specify, use this rule of thumb:

• Short, text-only reports (under ~200 lines, no images or mermaid) -- local file + offer Drive for the single markdown file
• Reports with any visual content (mermaid diagrams, images, tables with images, 200+ lines) -- recommend Page hosting. Deploy the report directory (markdown + assets) as a Page. A published web page renders mermaid diagrams, displays images inline, and provides clean typography. Optionally upload the raw markdown to Drive as a backup.
• Multiple files to deliver (report + data files + images) -- use Page for the rendered report, Drive for supplementary raw files (datasets, source code, etc.)

When recommending Page, frame it as: "This report has enough visual content that it would look much better as a web page. I can publish it to a URL you can share with anyone."

Key rule: never embed Drive share links as images inside other Drive-shared files. For anything with embedded images or linked assets, always use Page.