c-level-advisor/skills/board-deck-builder/SKILL.md
Assembles comprehensive board and investor update decks by pulling perspectives from all C-suite roles. Use when preparing board meetings, investor updates, quarterly business reviews, or fundraising narratives. Covers structure, narrative framework, bad news delivery, and common mistakes.
npx skillsauth add alirezarezvani/claude-skills board-deck-builderInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Build board decks that tell a story — not just show data. Every section has an owner, a narrative, and a "so what."
board deck, investor update, board meeting, board pack, investor relations, quarterly review, board presentation, fundraising deck, investor deck, board narrative, QBR, quarterly business review
/board-deck [quarterly|monthly|fundraising] [stage: seed|seriesA|seriesB]
Provide available metrics. The builder fills gaps with explicit placeholders — never invents numbers.
Every section follows: Headline → Data → Narrative → Ask/Next
3 sentences. No more.
Bad: "We had a good quarter with lots of progress across all areas." Good: "We closed Q3 at $2.4M ARR (+22% QoQ), signed our largest enterprise contract, and enter Q4 with 14-month runway. The strategic shift to mid-market is working — ACV up 40% and sales cycle down 3 weeks. Q4 priority: close the $3M Series A and hit $2.8M ARR."
6-8 metrics max. Use a table.
| Metric | This Period | Last Period | Target | Status | |--------|-------------|-------------|--------|--------| | ARR | $2.4M | $1.97M | $2.3M | ✅ | | MoM growth | 8.1% | 7.2% | 7.5% | ✅ | | Burn multiple | 1.8x | 2.1x | <2x | ✅ | | NRR | 112% | 108% | >110% | ✅ | | CAC payback | 11 months | 14 months | <12 months | ✅ | | Headcount | 24 | 21 | 25 | 🟡 |
Pick metrics the board actually tracks. Swap out anything they've said they don't care about.
One sentence on each variance. Boards hate "revenue was below target" with no explanation. Say why.
The forecast must have a confidence level. "We expect $2.8M" is weak. "High confidence $2.6M, upside to $2.9M if two late-stage deals close" is useful.
No feature lists. Only features with evidence of user impact.
Keep this short unless there's a material issue. Boards don't need sprint details.
The "asks" slide is the most important. Be specific. "We'd like 3 warm introductions to CFOs at Series B companies" beats "any help would be appreciated."
Boards see 10+ decks per quarter. Yours needs a through-line.
The 4-Act Structure:
This works for good news AND bad news. It's credible because it acknowledges reality.
Opening frame: Start with the one thing that matters most — the board should know the key message by slide 3, not slide 30.
Never bury it. Boards find out eventually. Finding out late makes it worse.
Framework:
What NOT to do:
| Mistake | Fix | |---------|-----| | Too many slides (>25) | Cut ruthlessly — if you can't explain it in the room, the slide is wrong | | Metrics without targets | Every metric needs a target and a status | | No narrative | Data without story forces boards to draw their own conclusions | | Burying bad news | Lead with it, own it, fix it | | Vague asks | Specific, actionable, person-assigned asks only | | No variance explanation | Every gap from target needs one-sentence cause | | Stale appendix | Appendix is only useful if it's current | | Designing for the reader, not the room | Decks are presented — they must work spoken aloud |
Quarterly (standard): Full deck, all sections, 20-30 slides. Sent 48 hours in advance.
Monthly (for early-stage): Condensed — metrics dashboard, financials, pipeline, top risks. 8-12 slides.
Fundraising: Opens with market/vision, closes with ask. See references/deck-frameworks.md for Sequoia format.
references/deck-frameworks.md — SaaS board pack format, Sequoia structure, investor tailoringtemplates/board-deck-template.md — fill-in template for complete board deckstools
Code review automation for TypeScript, JavaScript, Python, Go, Swift, Kotlin, C#, .NET, Java, C, C++, Rust, Ruby, PHP, and Dart/Flutter. Analyzes PRs for complexity and risk, checks code quality for SOLID violations and code smells, generates review reports. Use when reviewing pull requests, analyzing code quality, identifying issues, generating review checklists.
tools
Use when planning, funding, scoping, or synthesizing enterprise research across workstreams — clinical study design, R&D program finance, market sizing/surveys, or product/user research. Triggers on "design this clinical study", "what sample size", "R&D budget", "burn rate", "capitalize or expense", "TAM SAM SOM", "market sizing", "survey design", "segment the market", "plan user interviews", "usability test", "synthesize research insights". Forks context to route to one of four Research-Operations sub-skills (clinical-research, research-finance, market-research, product-research) and returns a digest. Distinct from ra-qm-team (regulatory submission), finance (corporate close/valuation), research/grants (funding discovery), product-team (persona/journey/live experiments), and marketing-skill (campaign analytics).
development
Use when managing the money for an internal R&D program or portfolio — building a multi-period program budget with the F&A (indirect) split, tracking burn rate and runway against value-inflection milestones, or routing R&D cost items to a capitalize-vs-expense determination. Every budget output surfaces its assumptions block; capitalize-vs-expense is decision-support only and routes to a named finance owner — it never books an entry or decides accounting treatment. Distinct from finance/financial-analysis (corporate DCF, close, valuation) and research/grants (funding discovery — this manages money already won).
development
Use when planning and synthesizing product/user research as a method-and-repository discipline — selecting the right method for the goal (generative interviews vs usability test vs concept test vs validation), computing method-based saturation/sample size with an explicit confidence level, or synthesizing coded observations into insights while flagging single-source anecdotes. Never fabricates user insight; an insight requires recurrence across independent participants. Distinct from product-team/ux-researcher-designer (persona/journey artifacts), product-discovery (discovery-sprint planning), and experiment-designer (live A/B) — this is the research-ops method + insight-repository layer.