Benchmark Due Diligence

Benchmark Due Diligence

Take a benchmark the user envies — a founder, KOL, company, or product whose success looks suspiciously shiny — and produce a teardown that ends in "what this means for ME", not a neutral report. The deliverable answers three questions a balanced briefing never does: How much of this success is real vs marketing bubble? How much is replicable method vs luck/timing? And what, specifically, can the commissioner do with it?

This is the adversarial, decision-oriented cousin of deep-research. Where deep-research builds a trustworthy picture of the world, this skill assumes the picture is inflated until proven otherwise and converts the survivors into the commissioner's own moves.

CRITICAL: run inline, never context: fork

This skill is an orchestrator — it spawns parallel collection + verification agents (via the Workflow tool, or Task agents) and may invoke other skills (deep-research, osint-investigate, qcc). Subagents cannot spawn subagents or call skills. Setting context: fork would silently break the entire fan-out. Do not add a `context` field. (Same constraint osint-investigate documents — it's a hard runtime rule, not a preference.)

The one rule that protects the commissioner: two injection channels

Everything the agents see flows through exactly two channels. Keeping them separate is the single most important discipline in this skill:

Why this split is non-negotiable: collection and verification agents take their input and run external WebSearch on it. If the commissioner's client names or strategy leak into those prompts, they get searched on the open web — a privacy breach. The mapping phase genuinely needs "who is the commissioner"; the collection phase must never see it. Encode this in the orchestration (see references/workflow_orchestration_template.md), don't rely on remembering it mid-run.

Phase 0 — nail the foundation by evidence, not appearance (do this BEFORE any agent)

The fastest way to waste a 12-agent fan-out is to build it on a foundation you inferred from appearances. Two failure modes recur and both have burned real runs:

1. Inferring relationships between entities from names/domains. "Their content lives at academy.example.com, and they're the founder, so they must own that community" — when in reality they were just an invited guest. A shared domain, a similar name, or co-occurrence is an observation, not ownership. Verify with an authoritative source before treating any A↔B relationship as fact. 2. *Treating the commissioner's client as the commissioner's asset. If the commissioner does service work for an accelerator/brand, that accelerator is the client's* asset — the commissioner can't leverage its audience or capital. Mapping the benchmark's playbook onto resources the commissioner doesn't actually control produces castles in the air.

So before fanning out, establish by evidence (not vibes):

• The benchmark's real entity graph — who owns whom, who merely partners/guests. Don't reason from names.
• The headline-claim attribution — the benchmark's whole narrative usually rests on one trophy stat ("took product X from 0 → 1M users"). Are they the founder, or the departed growth lead? This is the #1 to-verify target; write it into FACTS with a ⚠️.
• What the commissioner truly controls — separate owned assets from client/partner assets.

Write the results into FACTS (public half) and COMMISSIONER_CONTEXT (private half). A shaky foundation makes every downstream agent confidently wrong.

The four-phase orchestration

Use the Workflow tool (preferred — deterministic fan-out, see the ready-to-fill template in references/workflow_orchestration_template.md) or Task agents. Scale agent count to how thorough the user wants (a few dimensions for a quick read, 6+ with multi-vote verification for a deep audit).

Phase 1 + 2 — collect → verify, per dimension, as a pipeline (each dimension verifies the moment its collection finishes; no global barrier):

• Collection agent — objective stance. Every finding carries a source URL and a source_kind (对象自述/营销 vs 第三方独立信源 vs 混合). Anything not found goes in gaps — never filled by guessing.
• Verification agent — adversarial, default-skeptical stance. Grade every claim L1–L4 and rule 坐实 / 大体可信 / 存疑 / 证伪-水分. The job is to actively hunt falsifying evidence, especially for the headline claims (the trophy stat, "#1 ranking", funding amount, user counts). bubble_summary names the biggest water in that dimension.

Grading rubric, source_kind, verdicts, and both JSON schemas → `references/evidence_grading_rubric.md`.

Typical dimensions (tailor to the benchmark type — person / company / product): 1. Subject background + headline-claim attribution (the #1 bubble target) 2. Corporate base — entity, founding, funding/valuation 3. Core product/business real metrics — user counts, revenue, rankings, awards, cross-verified against third parties 4. Playbook teardown — platform matrix, persona, content types, how they borrow other people's audiences, how personal IP funnels to the product 5. Comparison sample — a structurally-similar peer or parallel path 6. Sector + how this class of playbook usually wins and usually fails

Phase 3 — synthesis: due-diligence conclusion (single agent, consumes all verdicts): 1. Real relationship map (correcting the common misreadings from Phase 0) 2. Bubble-busting table — claim | evidence level | verdict | one-line basis, sorted by most-water-first 3. Playbook teardown — concrete, copyable actions 4. Attribution breakdown (the core) — what share of the success is product vs market-timing vs personal-IP-marketing vs operations? Give % ranges with reasons, and explicitly split replicable method from luck / timing / non-transferable endowment.

Phase 4 — synthesis: what this means for the commissioner (single agent; consumes Phase 3 + COMMISSIONER_CONTEXT): 1. Resource-mapping table — benchmark's playbook elements × the commissioner's real resources; tag each cell ✅ borrow-able / ⚠️ not-replicable (luck/timing) / 🔄 already-doing / 🚫 bubble-don't-copy, one line each 2. Landing points — exactly how the commissioner uses it (their to-B service / their own IP / their tooling) 3. Action list + open questions (what's still unconfirmed)

Attribution weighting and the four-tag mapping framework → `references/attribution_and_resource_mapping.md`.

Don't rebuild what already exists

This skill's edge is the adversarial bubble-busting + attribution + commissioner-mapping layers. The plumbing underneath is not novel — reuse it:

• Fan-out collection / source governance — borrow the lead-agent + subagent pattern from deep-research. (What's unique here is the skeptical verification stance and the L1–L4 bubble grading, not the parallelism.)
• Person-subject identity / footprint checks — invoke osint-investigate (ACH hypothesis matrix, Bellingcat-style pivots) rather than re-deriving identity attribution.
• Mainland-China corporate registration / funding — invoke the qcc family of skills for 工商 data.
• Social-platform playbook data — the agent-reach CLI covers B站/小红书/抖音/YouTube/X.

Read before you run

• `references/evidence_discipline_traps.md` — the recurring traps (inferring relationships from appearances, headline-claim attribution, client-vs-asset, foundation-before-fan-out, grade-don't-binary, privacy leak) with real teardown war-stories. Read this first; it's where runs actually break.
• `references/evidence_grading_rubric.md` — L1–L4, source_kind, verdicts, collection/verification schemas.
• `references/attribution_and_resource_mapping.md` — attribution weighting + four-tag mapping + landing-point framework.
• `references/workflow_orchestration_template.md` — a ready-to-fill Workflow script with the FACTS / COMMISSIONER_CONTEXT injection split already wired in.

Next Step

After the due-diligence conclusion is ready, suggest the natural follow-on (opt-in, never auto-run):

Due-diligence teardown is done.

Options:
A) Render it as a shareable PDF report — pdf-creator (Recommended if this goes to a partner/team)
B) One dimension needs deeper neutral background — deep-research on that sub-topic
C) No thanks — the markdown teardown is enough

Attribution & Resource Mapping

The frameworks for Phase 3 (attribution) and Phase 4 (mapping onto the commissioner). This is where a teardown stops being "interesting research" and becomes "a decision."

Contents

• Attribution weighting (Phase 3)
• Replicable vs not
• Four-tag resource mapping (Phase 4)
• Landing points
• The one-line verdict

Attribution weighting (Phase 3)

Once the bubble is busted, the core question is: of the success that's actually real, how much comes from each factor? Weight four factors, give each a % range with reasons that cite the verdicts' evidence levels:

The output is a table of weights + a sharp split between replicable method and non-replicable luck/timing/endowment.

Worked example (anonymized): an AI-tool founder's growth attributed roughly as — market timing 25-35% (rode a funding hype cycle, not replicable) + personal-IP marketing 30-40% (the moves are replicable, but the numbers were inflated) + product strength 10-20% (narrative exceeds independent validation) + community 5-10%. One-liner: the moves are real, the numbers are inflated, the timing is unrepeatable.

Replicable vs not

For every attribution factor, label each component:

• Replicable method (learn-able) — a concrete, transferable action framework
• Not replicable (luck / timing / endowment) — hype-cycle dividend, a specific personal background, or the magnitude of the inflation itself

That last point matters: the inflation is a liability to inherit, not a method to copy. Replicating "claim 1M users when it was 500K" doesn't transfer the growth — it transfers the reputational risk that collapses when someone checks.

Four-tag resource mapping (Phase 4)

A table: each playbook element (rows) × each of the commissioner's resources (columns). Tag every cell:

• ✅ borrow-able — the commissioner can directly reuse this move
• ⚠️ not-replicable — luck / timing / resource mismatch; looks tempting but won't transfer
• 🔄 already-doing — the commissioner already has this; confirm, don't "add" it
• 🚫 bubble-don't-copy — inflation / reputational backfire; explicitly refuse

One line of reasoning per cell. The ⚠️ and 🚫 cells are as valuable as the ✅ ones — they stop the commissioner from betting on the parts that won't work.

Landing points

Mapping is abstract until it lands on exactly how the commissioner uses it. Organize landing points by the commissioner's resource types (e.g. their to-B service offering, their own personal IP, their tooling). For each, give 3-5 actions the commissioner can execute next, not someday. Anything that depends on an asset the commissioner doesn't own (Trap 3) is not a valid landing point.

The one-line verdict

Close every teardown with a single memorable line that compresses bubble + attribution into something the commissioner can repeat from memory. Shape: "the moves are real, the numbers are inflated; what you can steal is [the 2-3 action frameworks], what you can't is [the timing and the inflation]." If you can't compress it to one line, the attribution isn't sharp enough yet.

Evidence Discipline Traps

Real failure modes that have broken benchmark-DD runs. Read this first — it's where runs actually go wrong, and every trap is cheap to avoid and expensive to recover from.

Contents

• Trap 1: inferring relationships from appearances
• Trap 2: the headline-claim attribution
• Trap 3: client ≠ commissioner's asset
• Trap 4: foundation before fan-out
• Trap 5: grade, don't binary
• Trap 6: privacy leak into external search

Trap 1 — inferring relationships between entities from names/domains

The trap: the benchmark's content lives at community.example.com, they're a well-known founder, so you write "they run that community" into FACTS. The downstream agents inherit it and confidently build on a relationship that doesn't exist.

War-story (anonymized): a founder appeared to "own" a popular paid AI community because their viral post lived there. They were in fact an invited guest; the community belonged to a different educator entirely. Treating the guest spot as an owned channel inverted the whole competitive picture — and it was caught only because someone re-read the source and noticed the post literally said "[the community host] invited me to share."

The rule: a shared domain / similar name / co-occurrence is an observation, not ownership. Before any A↔B relationship enters FACTS, verify it against an authoritative source. Always distinguish "I observed X near Y" from "X owns Y."

Trap 2 — the headline-claim attribution is the #1 target

The trap: the benchmark's entire IP narrative rests on one trophy stat, and you take it at face value because it's repeated everywhere — but "everywhere" is the same PR reprinted N times.

War-story: the headline was "took product X from 0 → 1M users in a year." Verification found the person was the departed head of growth, not the founder; the real founder was someone else (the product's own makers list and registry proved it), and an independent outlet said "3 months to 500K," not "1 year to 1M." The trophy stat was borrowing a former employer's achievement, inflated on top.

The rule: find the one claim the subject's whole story depends on, flag it ⚠️ to-verify in FACTS, and make verifying its attribution (who actually did it) and its magnitude the highest-priority task in the whole run. Check the product's own about page, the registry, the Product Hunt makers list, LinkedIn — anything except the subject's own bio.

Trap 3 — the commissioner's client is not the commissioner's asset

The trap: the commissioner does service work for a big-name platform, so you map the benchmark's "leverage your audience" playbook onto that platform's audience. But the commissioner is a vendor, not the owner — they can't pull those levers.

War-story: a teardown mapped a benchmark's community-flywheel playbook onto an accelerator the commissioner appeared associated with. The commissioner was actually a paid service provider to that accelerator — they couldn't touch its enrollment or capital. The whole "what you can do" section was advice the commissioner literally could not execute, and had to be rewritten once the ownership was corrected.

The rule: in Phase 0, hard-split the commissioner's owned assets from client/partner assets. Only owned assets are valid mapping targets in Phase 4.

Trap 4 — establish the foundation before you fan out, not after

The trap: excited to start, you launch the multi-agent fan-out, then discover mid-run that two entities you told the agents were related actually aren't. Every result is now contaminated and the run has to be redone.

The rule: Phase 0 (verify the entity graph + headline attribution + commissioner resources) happens before the orchestration. It's a handful of authoritative lookups that save an entire re-run. Foundation first, fan-out second — never the reverse.

Trap 5 — grade, don't binary

The trap: the user is suspicious ("it's all bubble"), so the run reflexively debunks everything; or the opposite, it treats the survivors as fully proven. Both lose the signal.

The rule: the deliverable's value is separating real signal from water, not picking a side. Apply the L1–L4 + verdict ladder per-claim (see evidence_grading_rubric.md). The best teardowns conclude "the moves are real, the numbers are inflated" — a nuance that only exists if you resist judging the subject as a monolith.

Trap 6 — never let commissioner context leak into external search

The trap: to give the collection agents "context," you paste the commissioner's situation — including client names and strategy — into their prompts. Those agents then run WebSearch on it, and the commissioner's private business becomes a query on the open web.

The rule: the two-channel split (see SKILL.md) is a hard wall. FACTS (public, about the benchmark) → all agents. COMMISSIONER_CONTEXT (private) → only the Phase-4 mapping agent, which does no external search. Wire it into the orchestration so it cannot be forgotten mid-run — don't rely on remembering it.

Evidence Grading Rubric

How collection and verification agents tag and judge every claim. This is the machinery that turns "they say they're #1" into "category award + monthly #1, the annual-#1 claim is debunked."

Contents

• Two stances: objective collection vs adversarial verification
• source_kind (set during collection)
• Evidence levels L1–L4 (set during verification)
• Verdicts
• The grading discipline: grade, don't binary
• JSON schemas (collection + verification)

Two stances

Collection and verification run as separate agents with opposite postures. Never merge them — an agent told to both gather and judge rationalizes what it found.

source_kind (set during collection)

Tag every finding by where it came from — this is what later lets the verifier weight it:

• 对象自述/营销 (self-reported / marketing) — the subject's own blog, pitch deck, PR wire, founder interview. Treat as claims, not facts.
• 第三方独立信源 (independent third party) — registries, audited data, reporting that is not a reprint of the subject's PR.
• 混合 (mixed) — e.g., a media article that quotes the subject's numbers without independent verification.

Evidence levels L1–L4 (set during verification)

Bubble-busting is the act of moving a claim down from its self-asserted level. A "#1 of the year" asserted at L1 (the subject's bio) routinely collapses to "category award + a monthly #1" once checked against the platform's own award records at L4.

Verdicts

• 坐实 (confirmed) — L3/L4 backs it
• 大体可信 (largely credible) — plausible, partially corroborated, minor gaps
• 存疑 (doubtful) — single-source / unfalsifiable / internal contradictions
• 证伪-水分 (debunked — water) — falsifying evidence found; the claim is inflated or wrong

The grading discipline: grade, don't binary

The point is not to declare the benchmark a fraud. Most envied benchmarks are real success wrapped in inflated storytelling — and the trap cuts both ways: naive belief AND reflexive cynicism both destroy the signal. The verdict ladder forces the middle path: confirm what's solid, debunk what's water, mark the rest doubtful. A strong teardown's one-liner is usually shaped like "the moves are real, the numbers are inflated" — a nuance that only survives if you grade each claim instead of judging the subject as a monolith.

JSON schemas

Pass these as the schema option to each agent so the model is forced to return validated structure.

Collection output:

{
  "type": "object",
  "additionalProperties": false,
  "properties": {
    "dimension": { "type": "string" },
    "findings": {
      "type": "array",
      "items": {
        "type": "object",
        "additionalProperties": false,
        "properties": {
          "claim": { "type": "string", "description": "one fact or asserted claim" },
          "detail": { "type": "string" },
          "sources": { "type": "array", "items": { "type": "string" }, "description": "source URLs" },
          "source_kind": { "type": "string", "enum": ["对象自述/营销", "第三方独立信源", "混合"] }
        },
        "required": ["claim", "detail", "sources", "source_kind"]
      }
    },
    "gaps": { "type": "string", "description": "not-found / doubtful, to fill later — NEVER guessed" }
  },
  "required": ["dimension", "findings", "gaps"]
}

Verification output:

{
  "type": "object",
  "additionalProperties": false,
  "properties": {
    "dimension": { "type": "string" },
    "verdicts": {
      "type": "array",
      "items": {
        "type": "object",
        "additionalProperties": false,
        "properties": {
          "claim": { "type": "string" },
          "evidence_level": { "type": "string", "enum": ["L4", "L3", "L2", "L1"] },
          "verdict": { "type": "string", "enum": ["坐实", "大体可信", "存疑", "证伪-水分"] },
          "reasoning": { "type": "string" },
          "cross_sources": { "type": "array", "items": { "type": "string" }, "description": "URLs actually checked while verifying" }
        },
        "required": ["claim", "evidence_level", "verdict", "reasoning", "cross_sources"]
      }
    },
    "bubble_summary": { "type": "string", "description": "the biggest water in this dimension" }
  },
  "required": ["dimension", "verdicts", "bubble_summary"]
}

Workflow Orchestration Template

A ready-to-fill Workflow script for the four-phase fan-out. Fill the placeholders (AS_OF, FACTS, COMMISSIONER_CONTEXT, DIMENSIONS), keep the injection split intact, and run it via the Workflow tool. The schemas live in evidence_grading_rubric.md — paste them in or reference them.

The injection split (the thing you must NOT break)

• FACTS → every agent (collection, verification, synthesis A)
• COMMISSIONER_CONTEXT → only synthesis B (the mapping agent), which does no external search

Collection/verification agents run WebSearch on their prompt. If commissioner context reaches them, it's searched on the open web. This is Trap 6.

Template

export const meta = {
  name: 'benchmark-dd',
  description: '<one-line: bust the benchmark and map onto the commissioner>',
  phases: [
    { title: '采集' }, { title: '验证' },
    { title: '综合-尽调结论' }, { title: '综合-对你的应用' },
  ],
}

const AS_OF = '<YYYY-MM-DD>'  // stamp freshness; pass it in (Date.now() is unavailable in workflow scripts)

// PUBLIC verified facts about the benchmark — injected into ALL agents.
// Flag the headline trophy claim with ⚠️ as the #1 to-verify target (Trap 2).
const FACTS = [
  '【已核实地基事实（截至 ' + AS_OF + '）。站在此基础上深挖，不推翻已验证项，但为 ⚠️ 项找独立硬证据】',
  '- <verified entity relationships — who owns whom, who only guests/partners (Trap 1)>',
  '- ⚠️ <the headline claim whose attribution + magnitude must be cross-verified>',
].join('\n')

// PRIVATE commissioner reality — injected into the Phase-4 mapping agent ONLY.
const COMMISSIONER_CONTEXT = [
  '【委托人真实资源与诉求 —— 仅映射阶段可见，禁入外部搜索】',
  '- owned assets (valid mapping targets): <...>',
  '- client/partner assets (NOT leverageable — Trap 3): <...>',
  '- what they want to steal / the decision they face: <...>',
].join('\n')

const COLLECT_SCHEMA = { /* see evidence_grading_rubric.md */ }
const VERIFY_SCHEMA  = { /* see evidence_grading_rubric.md */ }

const DIMENSIONS = [
  { key: 'subject-bio',     label: 'subject background + headline-claim attribution', focus: '... ★ verify WHO actually did the trophy stat, and its real magnitude' },
  { key: 'corp-base',       label: 'corporate base + funding',                        focus: 'entity, founding, funding/valuation; qcc for mainland-China subjects' },
  { key: 'product-metrics', label: 'core product real metrics (bubble-bust)',         focus: 'cross-verify user counts / revenue / rankings / awards against third parties' },
  { key: 'playbook',        label: 'playbook teardown',                               focus: 'platform matrix / persona / how they borrow others’ audiences / IP→product funnel; agent-reach for socials' },
  { key: 'comparison',      label: 'comparison sample',                               focus: 'a structurally-similar peer or parallel path' },
  { key: 'sector-peers',    label: 'sector + same-class playbook',                    focus: 'how this class of playbook usually wins AND usually fails' },
]

log('Phase 1+2: fan-out collect → adversarial verify (bubble-bust)')
const verified = await pipeline(
  DIMENSIONS,
  (d) => agent(
    '你是尽职调查研究员，立场客观、只认证据。维度：' + d.label + '\n\n' + FACTS +
    '\n\n【本维度要砸实】\n' + d.focus +
    '\n\n【工具】优先 WebSearch/WebFetch；可 Bash 调 agent-reach(社媒) / qcc(工商) 增强，调不通回退，不卡死。' +
    '\n【纪律】每条 finding 带 source URL + source_kind；查不到写 gaps，禁脑补。',
    { label: '采集:' + d.key, phase: '采集', schema: COLLECT_SCHEMA, agentType: 'general-purpose' }
  ),
  (collected, d) => agent(
    '你是对抗性核查员，默认怀疑，专找水分。逐条打证据等级+裁决。\n维度：' + d.label +
    '\n采集结果：\n' + JSON.stringify(collected) +
    '\n【L4=硬数据可查实 / L3=多独立信源一致 / L2=单一可信第三方 / L1=仅自述营销】' +
    '\n【裁决 坐实/大体可信/存疑/证伪-水分】主动找证伪证据，尤其 headline 战绩/榜单/融资/用户量。bubble_summary 点最大水分。',
    { label: '验证:' + d.key, phase: '验证', schema: VERIFY_SCHEMA, agentType: 'general-purpose' }
  )
)
const clean = verified.filter(Boolean)

phase('综合-尽调结论')
const partA = await agent(
  '资深行业分析师。基于核查结果产出"尽调结论"(中文 markdown)。\n\n' + FACTS +
  '\n核查结果：\n' + JSON.stringify(clean) +
  '\n## 一、真实关系图（已核实，纠正常见误解）' +
  '\n## 二、破泡沫核查表（宣称|证据等级|裁决|依据，水分从大到小）' +
  '\n## 三、打法拆解（可操作动作）' +
  '\n## 四、归因拆解（产品/时机/IP/运营各占%；可复制 vs 运气/时机/禀赋）' +
  '\n要求：用证据说话引用 evidence_level；不确定标存疑，禁补细节。',
  { label: '综合:尽调结论', phase: '综合-尽调结论' }
)

phase('综合-对你的应用')
const partB = await agent(
  '委托人战略顾问，犀利只给能落地的判断。基于尽调结论+委托人资源产出"对你的应用"。\n【尽调结论】\n' + partA +
  '\n\n' + COMMISSIONER_CONTEXT +  // <-- the ONLY place this is injected
  '\n## 五、资源映射表（打法要素 × 委托人资源；✅可借鉴/⚠️不可复制/🔄已在做/🚫泡沫别学）' +
  '\n## 六、落点：委托人具体怎么用（每落点 3-5 个可执行动作）' +
  '\n## 七、行动建议 + 存疑项' +
  '\n要求：紧扣委托人真实资源，禁把客户当委托人自有资产；不说正确的废话。',
  { label: '综合:应用建议', phase: '综合-对你的应用' }
)

return { partA, partB, dimensionsVerified: clean.length }

Scaling to thoroughness

• Quick read: 3-4 dimensions, single-vote verification.
• Deep audit: 6+ dimensions; add a multi-vote refutation pass on the headline claims (spawn N skeptics per claim, kill if a majority refute) before synthesis.
• Agent count: ~2 per dimension (collect + verify) + 2 synthesis. 6 dimensions ≈ 14 agents — a real, token-heavy run. Tell the user the scale before launching.

After the run

The workflow returns { partA, partB }. Stitch them into one markdown file, drop it where research lives, and offer the Next-Step PDF render (see SKILL.md). Strip any agent self-talk preamble before the first ## heading.