benchmark-due-diligence

What the source does

• FilesystemNone observedNo reads or writes in the source
• NetworkNone observedNo outbound calls in the source
• ShellNone observedNo commands run in the source
• DependenciesPinnedNothing floats
• SecretsNone foundNo keys in source

Five audit layers

Gates applied: no behavioural pass.

AGENTS.md

Audit 0.4.1 · source sha 2abe588e0b98 · 22 Oct 2026Report an issue or request a re-scan

• Publisherdaymade GitHub userOwner of the repository this skill is read from
• Source folderdaymade/claude-code-skills/daymade-financial/benchmark-due-diligenceThe exact folder we audited
• LicenceMITAs the repository states it
• Commit pinned for this verdict2abe588e0b98A new audit runs when the source changes
• Repository statusNot archivedPushed today
• Sandboxed runNot runSkills are read, not executed; layer L4 is skipped

Its description: Runs adversarial due-diligence on a benchmark the user envies — a founder, KOL, company, or product whose success looks inflated — splitting marketing bubble from real signal, then mapping the validated playbook onto…

---
name: benchmark-due-diligence
description: >-
  Runs adversarial due-diligence on a benchmark the user envies — a founder, KOL, company, or
  product whose success looks inflated — splitting marketing bubble from real signal, then mapping
  the validated playbook onto the user's own resources. Use for 尽调/对标/拆解 a competitor, 抄/偷师 their
  playbook, or suspecting 水分/泡沫 in claims. Prefer over deep-research when debunking inflated claims,
  not a neutral briefing.
---

# 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:

| Channel | Content | Injected into |
|---|---|---|
| **FACTS** | Already-verified *public* facts about the benchmark (relationships, who-owns-what, the headline claim flagged `⚠️ to-verify`) | **Every** agent — collection, verification, synthesis |
| **COMMISSIONER_CONTEXT** | The commissioner's *private* reality — real resources, client names, strategic intent, what they can actually leverage | **Only the final mapping agent (Phase 4)** |

**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. Playb

Excerpt, first 6,000 characters of SKILL.md, verbatim from the audited commit. It is text from someone else’s repository, quoted so you can judge it before your agent reads it.

git clone https://github.com/daymade/claude-code-skills
git -C claude-code-skills checkout 2abe588e0b98

Works in

1. 2026-10-22
   ✓SAFE B 89 / 100

   first audit · source 2abe588e0b98

Questions about benchmark-due-diligence

• github.com/daymade/claude-code-skills/tree/main/daymade-financia — the audited source at commit 2abe588e0b98 and every finding aboveObserved · 22 Oct 2026

Spotted something wrong? Report a correction · Methodology