About strategy-doc
strategy-doc is a skill for writing strategy documents that make explicit choices and tradeoffs. It combines Rumelt's strategy kernel with Playing to Win's cascading choices to connect diagnosis, direction, and coordinated action.
Key features
- 01Structure strategy around diagnosis and policy
- 02Define coordinated actions
- 03Apply five cascading strategic choices
- 04Make tradeoffs and exclusions explicit
Use cases
- 01Draft a strategy grounded in a core challenge
- 02Narrow target customers and markets
- 03Turn a chosen direction into coordinated work
Install
Copy the command and run it in a terminal.
npx skills add https:/After installing, type/strategy-docin Claude Code to confirm it loaded.
Details
From the project READMEWrite strategy that forces hard choices. A strategy that doesn't say "no" to something isn't a strategy — it's a wish list. Strategy is not goals, not aspirations, and not a list of things you want to do. It's a coherent set of choices about where to play and how to win.
The Strategy Kernel (Richard Rumelt)
Every strategy document must contain these three elements:
1. Diagnosis
What's actually going on? Name the challenge clearly. A good diagnosis simplifies complexity by identifying the critical factors.
- "Our activation rate is 23% because new users don't understand the product's value in their first session."
- NOT: "We need to grow faster." (That's an aspiration, not a diagnosis.)
2. Guiding Policy
The overall approach for dealing with the challenge. This is the big directional bet — it rules things in AND rules things out.
- "Focus entirely on time-to-first-value for solo users before expanding to teams."
- NOT: "Improve the product across all dimensions." (That's not a choice.)
3. Coherent Actions
Specific, coordinated actions that execute the guiding policy. Actions should reinforce each other.
- "Rebuild onboarding as a guided first-project flow. Remove the team invite step from signup. Add inline tooltips on the three core features. Measure activation at 'first project completed' not 'account created.'"
Playing to Win Framework (Lafley/Martin)
Structure the strategy as five cascading choices:
- Winning Aspiration: What does winning look like? (Not revenue targets — the change you want to create)
- Where to Play: Which customers, segments, geographies, channels? Be specific about what you're NOT pursuing.
- How to Win: What's your competitive advantage in your chosen space?
- Capabilities: What must you be great at to win this way?
- Management Systems: How will you track whether the strategy is working?
Each choice constrains the next. If "Where to Play" doesn't narrow the field, it's not a choice.
Guidelines
- CRITICAL: Every strategy doc MUST include what you will NOT do. A strategy without tradeoffs is not a strategy.
- NEVER confuse strategy with goals. "Reach $10M ARR" is a goal. "Win the PLG segment by being 10x faster to deploy than enterprise alternatives" is strategy.
- NEVER list more than 3 strategic priorities. If everything is a priority, nothing is.
- ALWAYS include a diagnosis that names the core challenge. If you can't name the problem, you can't solve it.
- ALWAYS make the guiding policy falsifiable. Someone should be able to argue against it.
- NEVER write strategy in a vacuum. Ground it in competitive reality, customer evidence, and your actual capabilities.
Example: Good vs Bad
Bad guiding policy:
"We will build the best product in the market by focusing on quality, speed, and customer satisfaction."
Good guiding policy:
"We will win technical PMs at Series A-B startups by being the fastest path from customer insight to shipped feature — sacrificing enterprise compliance features and multi-team coordination to stay opinionated and fast."
The good version names who, names what you're sacrificing, and could be argued against.
Built on Good Strategy Bad Strategy (Richard Rumelt) and Playing to Win (Lafley/Martin). Skills from productskills.