Product Deep Research

Build a comprehensive research deliverable on any product or company. Final output is a single complete .md file with up to 8 fact-checked, primary-source-driven modules plus optional synthesis. Each module runs as a separate sub-agent into intermediate files at [product]/research/, then Phase 4 compiles everything into one shareable markdown document.

The skill adapts to product type. Indie SaaS, AI-native, OSS dev tools, enterprise B2B, and consumer apps need different research approaches. Phase 0 classifies the product so subsequent modules use the right framing and source mix.

When to use

The user wants comprehensive research, not a quick answer. Examples:

"帮我调研一下 Notion / Logseq / Tana"
"I want to do a deep dive on Heptabase"
"Build a competitor analysis on Linear"
"研究一下 Cursor 是怎么做起来的"
"Help me understand the PLG mechanics of Figma"

Phase 0: Classify the product

Do this FIRST, before any modules. Determine the product's shape along 3 dimensions. If the user didn't specify, infer from the product name and confirm in one short message.

| Dimension | Options | Affects | |---|---|---| | Funding & Origin | Indie / Bootstrapped / VC-backed / Big-tech-internal / Public | Module 1 (founder narrative depth), Module 8 (risk categories) | | Growth engine | Composition model — score active engines by weight (see below) | Module 4 (depth allocation per engine) | | Extensibility | Plugin / API / SDK / MCP / Marketplace / None | Module 5 (run / repurpose / skip) |

Growth engine composition

[!important] PLG is a spectrum, not a binary Many products have self-serve signup + freemium and get labeled "PLG." But if acquisition is actually driven by paid ads or KOL campaigns, and conversion by promotional discounting, the actual growth engine is Paid + KOL with a PLG veneer. Phase 0 must diagnose the actual combination from product actions, not the marketing narrative.

Growth is almost always a combination of engines at different maturity levels. Score each active engine 0–3:

| Score | Meaning | Evidence pattern | |---|---|---| | 3 | Primary — top 1-2 growth driver | Clear, attributable growth from this engine | | 2 | Significant — measurable contribution | Supporting evidence, meaningful volume | | 1 | Minor — exists but not moving the needle | Present but low impact or aspirational | | 0 | Absent | No evidence found |

Engine menu: Self-serve PLG · Paid acquisition · KOL/Influencer-led · Content/SEO · Sales-led · Platform-bundled · Network-effect · Community/WOM · Channel partnerships

PLG maturity checkpoint — when PLG ≥ 1, assess the loop:

Self-serve signup → 2. Free value without sales → 3. Organic Aha moment → 4. Self-serve upgrade → 5. Retention without human touch → (bonus) 6. Viral/referral loop

Verdict: Closed (stages 1-5 all work) · Partial (which stages break?) · Aspirational (PLG mechanics exist but growth actually driven by other engines)

[!tip] Inference from product actions You can infer engine composition from observable signals — app store ads, KOL partnerships, sales team hiring on LinkedIn, content volume, community size — but be cautious. Label inferences as （推测） / (inferred) and distinguish from confirmed data. The sub-agent in Module 4 will validate and deepen the Phase 0 hypothesis.

Output: a routing config string. Inject into every subsequent module prompt. Format:

{ funding: VC-backed, growth: "KOL(3)+Paid(3) | Platform(2) | PLG(1,aspirational)", extensibility: API }

The growth string lists engines scored ≥1, grouped by score tier, with PLG maturity appended when applicable.

Examples:

Obsidian → Indie / PLG-closed(3)+Community(3)+KOL(2) / Plugin
Linear → VC-backed / PLG-closed(3)+Sales(2)+Content(1) / API
Salesforce → Public / Sales(3)+Channel(2)+Platform(2) / Marketplace
NotebookLM → Big-tech-internal / Platform(3)+Content(2) / None
Substack → VC-backed / Network(3)+Creator-WOM(2)+Content(2) / None
VSCode → Big-tech-internal-OSS / Platform(3)+Community(3)+Plugin-ecosystem(2) / Plugin
Cursor → VC-backed / PLG-closed(3)+Community(2)+Content(2) / None (built-in only)
LibTV → VC-backed / KOL(3)+Paid(3)+Platform(2)+PLG(1,aspirational) / API+SDK

The classification gets written into MOC under "## Product classification" so readers see the lens upfront.

Phase 1: Capture context

Confirm 4 things (skip what's already given):

Product name — exact (e.g., "Linear", not "Linear Software")

Product scope (ask only when ambiguous) — During Phase 0 research, if the product turns out to be one of several products under a parent company (e.g., LibTV under LiblibAI, Copilot under GitHub/Microsoft, Notion Calendar under Notion Labs), ask the user:

"你想只调研 {PRODUCT}，还是调研 {PARENT} 的整个产品线？"
Default: just this product. A user who types a specific product name wants that product, not a company overview.
When scope is product-only, generate a {SCOPE_BLOCK} (template below) and inject it into every sub-agent prompt alongside {LENS_BLOCK}.
When product IS the company (e.g., Linear, Obsidian, Cursor), there's no ambiguity — skip this question and set {SCOPE_BLOCK} to empty string.

Scope block template — use only when scope == product-only for a sub-product:

SCOPE — This research is scoped to {PRODUCT} only, not {PARENT_COMPANY}'s full portfolio ({SIBLING_PRODUCTS}).
Rules:
- {PRODUCT} is the SUBJECT. Every section should focus on {PRODUCT}'s own story, data, and metrics.
- Sibling products may appear ONLY as context (e.g., "users flow from {SIBLING} → {PRODUCT}", "{PRODUCT} shares GPU infra with {SIBLING}"). Do NOT include sibling products' independent growth data, user counts, community metrics, pricing, or competitive analysis.
- Parent-level data (total users, total revenue, funding rounds) must be clearly labeled "{PARENT_COMPANY} overall" and NOT used as a proxy for {PRODUCT}. If {PRODUCT}-specific data is unavailable, state "（{PRODUCT} 单独数据未公开）" / "{PRODUCT}-specific data not publicly available" rather than substituting parent numbers.
- Founder story: cover only insofar as it explains WHY {PRODUCT} was built. Don't write a full founder profile of the parent company.

Output language — match the user's language (Chinese / English / etc.)
Optional: lens / your-product — Ask: "Do you have your own product / company you want this research filtered through? If yes, tell me its name and one-line positioning, and each module will conclude with implications for it. If not, the research stays neutral."
- Default: no lens. Only add the lens angle if the user actively provides their product info.
- When no lens, skip the synthesis decision list in Phase 4. Just deliver modules + MOC.

If user said "调研 Notion" with no other context: assume Chinese, no lens, proceed. If user said "调研 LibTV" → Phase 0 reveals LibTV is under LiblibAI → ask scope → default product-only.

Phase 2: Plan module set

Use Phase 0 routing to decide which modules to run. Always present the planned set to the user before running:

| Module | Run when... | Skip when... | |---|---|---| | 1 · Founders & Philosophy | Always | — (Big-tech products have product-team narratives; just thinner) | | 2-3 · Timeline & Business Model | Always | — | | 4 · Growth Engine | Always | — (composition-based, adapts to engine mix) | | 4b · Use Case Map | Always | — | | 5 · Extensibility & Ecosystem | extensibility ≠ "None" | extensibility == "None" | | 6 · Community & KOL Network | Always | — (source mix varies by product type) | | 7 · Competitive Landscape | Always | — | | 8 · Risks & Ceiling | Always | — |

Phase 3: Run modules

Use the prompts in references/module-prompts.md. For each module, spawn a general-purpose subagent with the Phase 0 routing config injected.

Recommended batching:

Batch A: Module 1 alone first — establishes founder/date anchors that subsequent modules verify against
Batch B: Modules 2-3, 4, 4b in parallel after A
Batch C: Modules 5 (if applicable), 6, 7, 8 in parallel

After each batch, update the MOC progress table.

Foreground vs background: foreground if user is waiting; run_in_background: true if user wants to multitask.

Path discipline (important): Sub-agents tend to save to parent directory. Always include the absolute path in the prompt: save to /full/path/<product>/research/<file>.md — NOT to parent. Verify path in deliverable summary; move file if wrong.

Phase 4: Compile to single-file deliverable

The Phase 3 modules wrote individual files to [product]/research/ as intermediate artifacts. Phase 4 compiles them into the single-file deliverable the user actually consumes.

Step 0.5: Fact-check key metrics (before MOC)

Before generating the MOC, independently re-verify the 5-8 most important quantitative claims across all modules. At minimum check:

Download / user counts (go to the actual App Store / Google Play page, not third-party aggregators)
Pricing (go to the actual pricing page)
Funding amounts and investors
Team size
Launch dates

If any number conflicts with what sub-agents reported, update the module file and flag the correction in MOC's "Already-corrected facts" section. This step exists because sub-agents inherit the orchestrator's context and rarely challenge pre-filled numbers — the orchestrator must close the loop.

Step 1: Generate MOC at `[product]/research/00-MOC.md`

Product classification section (Phase 0 routing — visible at top)
Recommended reading order (express / depth)
Key people with [[wikilink]] placeholders
Key numbers (verified vs inferred)
"Already-corrected facts" ⚠️ from research

Step 2: Generate synthesis (only if user provided a lens product)

Save to [product]/research/[their-product]-decisions.md:

❌ Anti-targets
✅ Core decisions (grouped: growth / product / business)
💎 Differentiation points
🎯 Wedge selection

Skip this step entirely if no lens — go directly to Step 3.

Step 3: Compile to single .md file ⭐ (PRIMARY DELIVERABLE)

Compile MOC + all modules + synthesis into [product]/[product]-research.md. This is the file the user consumes:

PRODUCT=<product-slug>
OUT="$PRODUCT/$PRODUCT-research.md"

{
  # Top-level frontmatter
  echo '---'
  echo "title: $PRODUCT Research"
  echo "type: full-document"
  echo "date: $(date +%Y-%m-%d)"
  echo "tags: [$PRODUCT/research, full-doc]"
  echo '---'
  echo ''
  echo "# $PRODUCT Research"
  echo ''

  # Compile each file: strip frontmatter, demote all headings by one level
  for f in $PRODUCT/research/*.md; do
    awk '/^---$/ {n++; next} n>=2' "$f" \
      | awk '/^#+ / { print "#" $0; next } { print }'
    echo ''
    echo '---'
    echo ''
  done
} > "$OUT"

echo "✅ Compiled to $OUT ($(wc -c < "$OUT") bytes, $(wc -l < "$OUT") lines)"

What this does:

Strips per-module YAML frontmatter (lines between the first two ---)
Demotes all headings by one level (# X → ## X, ## Y → ### Y, etc.) so the compiled file has a single top-level title
Joins sections with --- separators

The single .md file is the deliverable. The [product]/research/ folder contains intermediate artifacts — keep for Obsidian users who want the multi-file vault, or delete after compilation.

Confirm with the user where they want the final file (default [product]/[product]-research.md).

Hard rules (load-bearing)

These principles produce grounded, durable research. Every agent prompt enforces them:

Challenge assumptions. The user's brief is often partially wrong (founder location, dates, prices, attribution). Verify against primary sources. Surface corrections in > [!warning] callouts. Don't silently fix — the user wants to know what was wrong.
Primary sources beat secondary. Founder personal blogs > official site > forum founder posts > podcast interviews > Hacker News threads >> Reddit summaries / "Top 10" articles.
Real quotes, attributed. Every philosophical or pain-point claim must have an original-language quote with URL. If unavailable, label 未找到一手原话 / "primary source not found" — never paraphrase as if it were a quote.
Honest about gaps. If a source is inaccessible (Reddit blocking, X requires login), say so in the report's "Sources" section. Never fabricate.
Length budget per module — pick the column matching output language. When constructing the sub-agent prompt, substitute the language-appropriate number into the prompt's "Length: X chars" constraint line:

| Module | Chinese chars | English chars | |---|---|---| | Foundational (1, 2-3) | 1500-2200 | 4500-6500 | | Heavy (4 — growth motion) | 4000-5500 | 12000-16500 | | Standard (4b, 5, 6, 7, 8) | 2500-4500 | 7500-13500 |

See references/output-format.md for the full table including MOC and synthesis budgets.
Save to correct path. Absolute path in agent prompt. Verify in deliverable.
Don't pre-fill unverified metrics into sub-agent context. Orchestrator's Phase 0 search results may contain cached/stale data (e.g., download counts, revenue, user numbers change fast). When passing context to sub-agents, mark key metrics as （待验证） / (unverified) rather than stating them as fact. Sub-agents anchor on whatever the orchestrator writes — one wrong number in the KEY CONTEXT block propagates to all 7+ modules as if verified. Third-party aggregators (AppBrain, SimilarWeb, Getlatka) lag behind primary sources; always prefer official store pages, founder statements, or SEC filings. Module 2-3 (Timeline & Business Model) should be explicitly instructed to independently verify all quantitative claims regardless of what the orchestrator provided.

Output conventions

Obsidian-style markdown. See references/output-format.md for full conventions. Essentials:

YAML frontmatter every file: title, type, module, date-created, date-updated, status, tags
Wikilinks for cross-refs: [[01-founders-philosophy]], [[Person Name]]
Callouts: > [!info], > [!quote], > [!important], > [!warning], > [!danger], > [!tip]
Tables for structured comparisons
All claims backed by URLs in per-file "Sources" section

Worked examples

Example 1: Product IS the company (no scope question)

User: "调研 Linear 给我看，我没在做竞品"

Claude (using this skill):

Phase 0 — classify Linear:

Funding: VC-backed (Sequoia, Accel)
Growth engines: PLG-closed(3) + Sales(2) + Content(1) — devs adopt bottom-up (PLG loop fully closed), mid-market+ has sales overlay
Extensibility: API (no plugins, has API + webhooks)
Routing: { funding: VC-backed, growth: "PLG-closed(3)+Sales(2)+Content(1)", extensibility: API }

Phase 1:

Product: Linear ✓
Scope: no ambiguity — Linear IS the company. Skip scope question. {SCOPE_BLOCK} = empty.
Language: Chinese ✓ (user spoke Chinese)
Lens: none (user said 没在做竞品)

Phase 2: Plan all 8 modules. Module 4 deep-dives PLG (primary, loop closed) + Sales (secondary) + Content (minor), with PLG maturity checkpoint. Module 5 researches the API ecosystem (not plugins). Module 8 risk categories include VC pressure + category disruption.

Phase 3:

Batch A: Module 1
Batch B: Modules 2-3, 4, 4b in parallel
Batch C: Modules 5, 6, 7, 8 in parallel
All save to linear/research/ with absolute paths

Phase 4:

Generate linear/research/00-MOC.md with Product Classification at top
Skip synthesis (no lens)
Compile to linear/linear-research.md — single file with all 8 modules + MOC, headings demoted, frontmatter unified

Final deliverable: linear/linear-research.md — single complete markdown file (~30k Chinese chars / ~90k English chars), fact-checked, primary-source-driven. Intermediate linear/research/ folder kept for reference (or deleted after compilation).

Example 2: Product is a sub-product (scope question triggers)

User: "帮我调研一下 LibTV"

Phase 0 — classify LibTV:

Funding: VC-backed (Sequoia China + CMC Capital)
Growth engines: KOL(3)+Paid(3) primary | Platform-bundled(2) secondary | PLG(1, aspirational — self-serve exists but acquisition driven by KOL/ads)
Extensibility: API + SDK (LibTV Skill API / OpenClaw)
Discovery: LibTV is a sub-product of LiblibAI (哩布哩布), which also operates an image generation platform and Lovart (design agent)