Boardroom STORM · structure
How Boardroom STORM works
The operating model, the full copy-paste prompt sequence, and worked examples for the adaptation of Stanford’s STORM method this skill runs inside Claude. The most important discipline is outline before draft: STORM’s contribution is not prettier prose, it is front-loaded research organization before a single paragraph gets written.
The operating model
The pipeline
Each stage finishes before the next begins. Research is fully separated from writing — the source ledger, interview briefs, and contradiction map all exist before the outline, and the outline exists before any prose.
- 0Research charterScope the decision, audience, horizon, sources, and output before anything else.
- 1Perspective discoveryGenerate 8–10 decision-relevant lenses, each with its own questions and blind spot.
- 2Source scoutBuild a per-perspective source ledger with credibility and freshness ratings — retrieve before synthesizing.
- 3Simulated expert interviewsInterview each persona against the ledger: facts vs interpretation vs implication, citation or [Unverified].
- 4Contradiction mapSurface conflicts, evidence asymmetries, incentives, and the unknown unknowns the perspectives expose.
- 5Source-mapped outlineOrganize by logic and map every claim to a source — the pivotal discipline: outline before draft.
- 6Grounded draftWrite only from the outline, cite claims, name uncertainty, prefer tables.
- 7Co-STORM moderator passA skeptical moderator hunts missing stakeholders, source bias, weak reasoning, and decision risks.
- 8Final outputExecutive memo, persona action table, what-would-change-this, and a 7-day plan.
When to use it
High cost of a shallow answer
Reach for Boardroom STORM when being early and right actually matters — entering a market, writing a public thesis, running diligence on a startup, evaluating a new protocol, mapping competitors, preparing a board memo, or deciding whether a trend is signal or noise. Do not use it for a single factual lookup; Claude’s web search handles those in one or two calls. The sweet spot is an ambiguous topic where five smart people would disagree before converging.
The full prompt sequence
Nine prompts, run in order
Replace the bracketed text and run them in order, with web search or research mode enabled when current facts matter. (The skill itself runs this sequence for you — these are here so you can drive it by hand or adapt a stage.)
You are going to run Boardroom STORM, an adaptation of Stanford STORM: Synthesis of Topic Outlines through Retrieval and Multi-perspective Question Asking. Topic: [TOPIC] Decision context: [What decision, thesis, memo, article, or strategy this research will inform] Primary audience: [Founder / investor / builder / board / product team / analyst readership] Time horizon: [e.g., current state, next 12 months, 3-5 years] Geography or segment: [if relevant] Source hierarchy: prioritize [primary filings, company docs, technical docs, academic papers, regulatory docs, reputable journalism, expert blogs, podcasts, etc.] Output target: [investment memo / market map / competitive analysis / product strategy / long-form article / board memo] Rules: 1. Separate research from writing. 2. Do not draft the final piece until the source ledger, interview briefs, contradiction map, and outline are complete. 3. Cite sources for factual claims when web/research tools are available. 4. If a claim cannot be verified, mark it as Unverified rather than smoothing over it. 5. Maintain an uncertainty ledger with weak claims, stale sources, contradictions, and missing data. First, restate the research charter in 8 bullets and identify any assumptions you will make.
Run the Perspective Discovery stage. Generate 8-10 distinct research perspectives for [TOPIC]. Do not use generic labels only. Each perspective should represent a real decision lens that would ask different questions. Required perspectives to consider: - Practitioner/operator who deals with this daily - Customer/user or buyer - Incumbent competitor - Startup challenger - Regulator or policy expert - Economist/business model analyst - Technical architect or engineer - Skeptic/bear-case analyst - Historian/comparable-cycles analyst - Investor/capital allocator For each perspective, provide: 1. Persona name 2. Why this lens matters for the decision 3. What this persona knows that others miss 4. 5 sharp questions this persona would ask 5. 3 likely source types this persona would trust 6. One blind spot this persona is likely to have End with a ranked list of the 12 highest-leverage questions across all perspectives.
Run the Source Scout stage for [TOPIC]. Using the perspective list above, build a source plan before answering the research questions. For each perspective: 1. List the exact queries you would run or source categories you would inspect. 2. Identify the most authoritative source types for that perspective. 3. State what evidence would confirm, weaken, or falsify that perspective's likely thesis. Then, if web/research tools are available, gather sources and create a source ledger with: - Source title - URL - Publisher/author - Date - Perspective(s) it informs - Key claims or data points - Credibility rating: High / Medium / Low - Freshness rating: Current / Potentially stale / Historical - Notes on bias or limitations Do not synthesize yet. Return the source ledger first.
Run the Simulated Expert Interview stage. For each perspective, simulate a 6-turn interview between: - Interviewer: a rigorous analyst trying to understand [TOPIC] - Expert: the persona for that perspective, grounded only in the source ledger and clearly marked assumptions Interview rules: 1. The interviewer asks one question at a time. 2. Each follow-up must build on the previous answer. 3. The expert must cite the relevant source from the ledger for factual claims, or say Unverified. 4. The expert must distinguish facts, interpretations, and implications. 5. The final answer from each expert must include: strongest claim, weakest claim, what would change their mind, and the one question nobody else is asking. Output format: - Perspective name - 6 Q&A turns - Evidence table - Claims to carry forward - Claims to discard or verify later
Run the Contradiction Map stage. Using the interview briefs and source ledger, identify: 1. Direct contradictions: where two perspectives make incompatible claims. 2. Evidence asymmetries: where one side has stronger evidence than another. 3. Incentive conflicts: who benefits if a given interpretation becomes accepted. 4. Timing conflicts: what may be true now but false in 12-24 months. 5. Definition conflicts: where people use the same words to mean different things. 6. Missing perspectives: who was not represented and why that could matter. 7. Unknown unknowns: questions that emerged only because the perspectives interacted. Create a table with columns: - Issue - Perspectives in conflict - Claim A - Claim B - Evidence strength - What would resolve it - Decision implication End with: - What all perspectives agree on - What nobody adequately addressed - The 5 facts most likely to change the conclusion
Run the Outline Synthesis stage. Create a source-mapped outline for [OUTPUT TARGET] on [TOPIC]. Requirements: 1. Start with the decision the reader needs to make. 2. Organize sections by logic, not by the order sources were found. 3. For each section, list the claims it will make and the sources that support each claim. 4. Include a section for contradictions and open questions. 5. Include a section for implications by persona: founder, entrepreneur/operator, builder/product leader, investor. 6. Do not write prose yet except for section descriptions. Output: - Working title - One-sentence thesis - Reader promise - Detailed hierarchical outline - Source map by section - Claims excluded because evidence is weak - Open questions to verify before drafting
Draft the [OUTPUT TARGET] from the approved outline. Rules: 1. Use only the source-mapped outline, source ledger, interview briefs, and contradiction map. 2. Every factual claim needs an inline citation when citations are available. 3. Do not hide uncertainty; name it precisely. 4. Write for [AUDIENCE] with an investor-grade, practical tone. 5. Include concrete implications for founders, entrepreneurs/operators, builders, and investors. 6. Prefer tables where comparison matters. 7. Avoid generic AI prose: no vague "transformative," "game-changing," or "rapidly evolving" unless the evidence justifies it. Structure: - Executive thesis - Why now - What the evidence says - Contradictions and open questions - Persona-specific implications - Action checklist - Final decision memo / conclusion
Run a Co-STORM-style Moderator Pass on the draft. Act as a skeptical moderator whose job is to find unknown unknowns, source bias, weak reasoning, and decision risks. Review the draft for: 1. Missing stakeholder perspective 2. Overweighted source cluster 3. Unsupported causal claim 4. Over-association of unrelated facts 5. Stale or geography-specific evidence presented too broadly 6. Incentive misread 7. Technical feasibility gap 8. Regulatory or compliance blind spot 9. Competitive response not considered 10. Investor-relevant downside case Return: - 10 required fixes ranked by importance - A revised thesis if needed - A revised outline if needed - Confidence scores for the 10 most important claims - A final uncertainty ledger - The 5 diligence questions a serious investor or board member would ask next
Produce the final version. Incorporate the moderator fixes. Preserve nuance, citations, and uncertainty. Add: 1. A one-page executive memo at the top. 2. A persona-specific action table for founders, entrepreneurs/operators, builders, and investors. 3. A "what would change this conclusion" section. 4. A "next 7 days" action plan. 5. A clean source and claim audit table if citations are available. Before finalizing, confirm that: - The draft answers the original decision context. - No major claim lacks support or a caveat. - Contradictions are explicit rather than buried. - The conclusion is actionable, not just informative.
Persona use cases
What each reader gets
For founders, the value is not more research — it is faster convergence on a wedge, buyer pain, incumbent weakness, regulatory friction, and a believable sequencing plan. For investors, it is a sharper contradiction map that separates facts from narratives, incentives from evidence, and bull cases from falsification tests.
A founder researching “AI-native compliance operations for fintechs” should force Claude to interview at least these perspectives: compliance officer, fintech founder, bank partner, regulator, AI engineer, workflow buyer, incumbent GRC vendor, and skeptical CFO. The useful insight will not come from a single answer about “AI in compliance.” It will come from contradictions among buyer trust, auditability, cost reduction, model risk, and integration burden. The output should be a memo with four decisions: which compliance workflow to start with, which buyer owns the budget, what proof is needed to earn trust, and what incumbent response could kill the wedge.
An investor researching a stablecoin infrastructure company should ask Claude to separate payment-volume narratives from float economics, regulatory constraints, banking partner risk, developer adoption, reserve transparency, and competitive response. The diligence value is in the contradiction map: one perspective may show explosive developer interest while another shows that compliance distribution or bank-partnership fragility constrains monetization. The final output should include a bull case, bear case, variant perception, key metrics to request from management, regulatory watch items, and the three facts that would change the investment conclusion.
A builder evaluating agentic customer operations should ask Claude to interview support leads, integration engineers, security reviewers, frontline agents, CFOs, and customers. The research should distinguish automatable tasks from escalation-heavy workflows, because product feasibility depends less on demo quality than on exception handling, audit trails, permissioning, and integration with existing systems. The output should be a product memo with workflow ranking, data requirements, integration dependencies, acceptance criteria, and the risks that would prevent deployment in regulated environments.
Quality control
Five rules
- Never skip the source ledger. STORM is retrieval plus question asking, not brainstorming with academic branding.
- Never draft before the outline is source-mapped. The Stanford implementation explicitly separates pre-writing from writing.
- Never let one persona dominate. Co-STORM’s value comes from discourse among agents and user steering, not a single authoritative voice.
- Never hide uncertainty. The STORM paper itself flags source-bias transfer and over-association of unrelated facts as open challenges.
- Never confuse Claude’s confidence with evidence. It can synthesize many sources, but you still inspect citations and decide whether the evidence is adequate for the decision.
What it is not
Honest limits
Boardroom STORM is not a replacement for the official Stanford codebase — a modular implementation with retrieval integrations, STORM and Co-STORM workflows, and a live research preview. This is an adaptation for people who want the reasoning pattern without running the package.
It is also not a substitute for expert diligence, legal advice, financial analysis, customer calls, or technical validation. It is a better way to create the first serious map of a problem space, find contradictions, and decide where human work should go next.
Source & attribution
This breakdown adapts Linas Beliūnas — “Stanford STORM × Claude”, which in turn builds on Stanford’s STORM research from the OVAL Lab.
- STORM paper: arxiv.org/abs/2402.14207
- STORM repository: github.com/stanford-oval/storm
- Co-STORM paper: aclanthology.org/2024.emnlp-main.554