1---
2name: crypto-whitepaper-writer
3description: Write a credible, well-structured whitepaper for any crypto/blockchain project (L1 chain, DeFi protocol, oracle network, stablecoin, token system) — grounded in the structural and rhetorical patterns of Bitcoin, Ethereum, Uniswap, Chainlink, and MakerDAO, not generic ICO-hype templates. Use whenever asked to draft, outline, or review a crypto/Web3 whitepaper.
4---
5
6# Crypto Whitepaper Writer
7
8## Why this skill exists
9
10Most AI-generated crypto whitepapers read like marketing decks: vague "revolutionary" language,
11unbacked security claims, a roadmap standing in for proof, tokenomics as decoration. The five
12most-cited whitepapers in the industry — Bitcoin, Ethereum, Uniswap, Chainlink, MakerDAO — share a
13different discipline instead: problem-first framing, incremental mechanism-building, named threat
14models, and per-actor incentive analysis. This skill encodes that discipline so the output reads
15like engineering, not a pitch.
16
17See `reference.md` for the full research base: archetype skeletons, craft principles, anti-patterns,
18and the pre-publish checklist. Read it before drafting.
19
20## Step 1 — Gather inputs before writing a word
21
22Do not start drafting until you have, from the user:
23
24- **The problem** this project solves, in one sentence, with a concrete scenario of what fails
25 without it.
26- **The project archetype** — the closest match in `reference.md` → Archetypes: base-layer
27 consensus/settlement, DeFi mechanism (AMM/lending/derivatives), oracle/coordination network,
28 stablecoin/collateral system, or application-layer protocol/token system.
29- **The core mechanism** — what actually happens on-chain/off-chain, in enough detail to describe a
30 state transition or formula, not just a feature list.
31- **Token existence and role** — if a token exists, what specific mechanical function does it serve
32 (fee payment, collateral, staking/slashing, governance weight)? If the project doesn't need a
33 token, say so explicitly rather than inventing tokenomics to look complete.
34- **Known limitations / open risks** the team is willing to state honestly.
35
36If any of these is missing or vague, ask before drafting — never fabricate a problem statement, team
37background, adoption numbers, or token model to fill a gap.
38
39## Step 2 — Pick the section skeleton, calibrate length
40
41Match the archetype to its skeleton in `reference.md`. Don't force every whitepaper through an
42identical template — Bitcoin has no tokenomics section; MakerDAO has no proof-of-work security proof.
43Use the shared spine (problem → mechanism → actor/incentive analysis → threat/risk model →
44architecture → [governance/token, only if applicable] → limitations → conclusion), and cut whatever
45doesn't apply to this project.
46
47Length follows mechanism complexity, not a fixed page count — Bitcoin proves its point in 9 pages;
48MakerDAO needs far more because it coordinates more actors and failure modes. Let each section run as
49long as the idea needs and no longer (anti-pattern: forced symmetry). If the project has a token or
50makes any financial/return-implying claim, include a short disclaimer (Uniswap's precedent) stating
51the document is not investment advice.
52
53## Step 3 — Draft section by section, applying the craft principles
54
55Work through `reference.md`'s craft principles as each section gets written. The ones that matter
56most in practice:
57
58- Open with a failure scenario, not a mission statement.
59- Build the mechanism from a minimal model upward — don't state the final design cold.
60- Every security or performance claim gets a number, threshold, or named proof — never an adjective
61 alone ("highly secure" is not a claim).
62- Every incentive-driven actor (miner, LP, oracle node, keeper, validator) gets its own paragraph
63 naming exactly what they earn and what punishes defection.
64- Name specific attack vectors and pair each with its specific countermeasure.
65- Include at least one worked, traceable example — a transaction walkthrough, a numeric calculation,
66 a step-by-step lifecycle.
67- If this design revises or extends a known predecessor, write it as an explicit delta (what changed
68 and why), not a from-scratch re-explanation.
69
70## Step 4 — Run the anti-pattern filter before showing a draft
71
72Scan against `reference.md`'s anti-pattern list. Any hit is a reason to rewrite the line, not soften
73it: price predictions or market-cap claims, unverifiable team/advisor credentials used as an
74argument, roadmap phases presented as proof of viability, a tokenomics table with no stated
75mechanical purpose, novelty claimed without naming what came before, a security claim with no threat
76model behind it, a missing limitations section, buzzwords substituting for a mechanism description.
77
78## Step 5 — Self-check and disclose gaps
79
80Before finalizing:
81
82- Confirm every numeric or technical claim traces to something the user provided or a cited external
83 source — flag anything you inferred rather than were told.
84- Confirm a limitations/risks section exists and isn't hollow.
85- Run `reference.md`'s pre-publish checklist and state the result (pass/fail per item, or a
86 self-rating) to the user before calling the draft done — don't ship a whitepaper without surfacing
87 what's unresolved.
88
89## Output format
90
91Markdown, sections matching the chosen archetype skeleton, an abstract at the top, references/sources
92at the bottom if external material was used. No emoji, no bolded label scaffolding (`Problem:`,
93`Solution:`), no forced symmetry between sections — a simple idea gets a short section, a hard one
94gets a long one, exactly as the five reference papers do.
95
96Cite every external claim (a cryptographic primitive, a competitor's known limitation, a market fact)
97inline with a bracketed marker (e.g. `[1]`) resolving to a numbered reference list at the end — never
98assert an outside fact with no traceable source. See `reference.md` → Calibration examples for what a
99compliant vs. non-compliant sentence looks like before you draft the real thing.
