Imported from mingaling19/product-deep-research (SKILL.md). Install upstream with npx skills add mingaling19/product-deep-research. Copyright stays with the author.

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.

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:

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:

1. 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):

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

2. 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.
   

3. Output language — match the user's language (Chinese / English / etc.)

4. 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:

Phase 3: Run modules

Read references/module-prompts.md before running modules. For each selected module, use the platform's sub-agent mechanism to spawn a capable research agent 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: run in the foreground if the user is waiting; use the platform's background execution mode, when available, if the 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:

1. 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.

2. Primary sources beat secondary. Founder personal blogs > official site > forum founder posts > podcast interviews > Hacker News threads >> Reddit summaries / "Top 10" articles.

3. 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.

4. Honest about gaps. If a source is inaccessible (Reddit blocking, X requires login), say so in the report's "Sources" section. Never fabricate.

5. 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.

6. Save to correct path. Absolute path in agent prompt. Verify in deliverable.

7. 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. Read references/output-format.md before compiling the deliverable. 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 给我看，我没在做竞品"

Agent (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)

Phase 1:

• Product: LibTV
• Scope: ambiguity detected — LibTV is one of LiblibAI's products. Ask user:

  "LibTV 是 LiblibAI 旗下的一个子产品（另有 LiblibAI 图像平台和 Lovart 设计 Agent）。你想只调研 LibTV，还是调研 LiblibAI 整个产品线？默认只调研 LibTV。"

  • User says "只调研 LibTV" (or doesn't reply → default product-only)
  • Generate {SCOPE_BLOCK} with PARENT=LiblibAI, SIBLINGS=LiblibAI图像平台/Lovart
• Language: Chinese
• Lens: none

Effect on modules: Each sub-agent gets the scope block + growth composition. Module 4 (growth) deep-dives KOL + Paid engines first (they're primary), then Platform distribution (secondary), and runs PLG maturity checkpoint — diagnosing the loop as aspirational since acquisition is KOL/ad-driven. Module 6 (community) maps LibTV-specific communities, not the broader SD model-sharing ecosystem. LiblibAI's platform appears only as "traffic source" or "shared infrastructure", not as a co-subject.

Edge cases

• Product is obscure / very new: limited public info. Run modules 1, 2-3, 4b, 7 only. Other modules will be too thin. Be explicit about data gaps.
• Product is dead / deprecated (e.g., Mem 1.0, Roam Research late stage): research becomes "post-mortem flavored". Module 8 becomes "what killed it / what's killing it". Still valuable as cautionary tale.
• Internal company tool with no public info: cannot research. Tell the user upfront.
• Language ambiguous: ask once.

References

• Read references/module-prompts.md before dispatching research modules.
• Read references/output-format.md before writing or compiling deliverables.