strategy-doc
Write product strategy documents with real tradeoffs and clear choices. Use when asked to write a product strategy, define strategic direction, create a strategy doc, or articulate where to play and how to win. Built on Playing to Win and Rumelt's Strategy Kernel.
What this skill does
Write 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: 1. **Winning Aspiration:** What does winning look like? (Not revenue targets — the change you want to create) 2. **Where to Play:** Which customers, segments, geographies, channels? Be specific about what you're NOT pursuing. 3. **How to Win:** What's your competitive advantage in your chosen space? 4. **Capabilities:** What must you be great at to win this way? 5. **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](https://github.com/assimovt/productskills).*
Related in Writing & Docs
jax-development
IncludedUse this skill when the user is writing, debugging, profiling, refactoring, reviewing, benchmarking, parallelising, exporting, or explaining JAX code, or when they mention JAX, jax.numpy, jit, grad, value_and_grad, vmap, scan, lax, random keys, pytrees, jax.Array, sharding, Mesh, PartitionSpec, NamedSharding, pmap, shard_map, Pallas, XLA, StableHLO, checkify, profiler, or the JAX repo. It helps turn NumPy or PyTorch-style code into pure functional JAX, fix tracer/control-flow/shape/PRNG bugs, remove recompiles and host-device syncs, choose transforms and sharding strategies, inspect jaxpr/lowering/IR, and benchmark compiled code correctly.
nature-article-writer
IncludedDrafts, rewrites, diagnostically critiques, and style-calibrates primary research manuscripts for Nature and Nature Portfolio journals. Use when the user wants a Nature-style title, summary paragraph or abstract, introduction, results, discussion, methods, figure legends, presubmission enquiry, cover letter, reviewer response, or when a scientific draft sounds generic, jargon-heavy, structurally weak, or AI-ish and needs precise, broad-reader-friendly prose without inventing data, analyses, or references. Best for primary research articles and letters rather than reviews or press releases unless explicitly adapting one.
deckrd
IncludedDocument-driven framework that derives requirements, specifications, implementation plans, and executable tasks from goals through structured AI dialogue. Use when user says "write requirements", "create spec", "plan implementation", "derive tasks", "structure this feature", "break down into tasks", or "document this module". Also use for reverse engineering existing code into docs (/deckrd rev). Do NOT use for direct code writing — use /deckrd-coder after tasks are generated. Do NOT use when the user only wants to run or fix existing code without planning.
clinical-decision-support
IncludedGenerate professional clinical decision support (CDS) documents for pharmaceutical and clinical research settings, including patient cohort analyses (biomarker-stratified with outcomes) and treatment recommendation reports (evidence-based guidelines with decision algorithms). Supports GRADE evidence grading, statistical analysis (hazard ratios, survival curves, waterfall plots), biomarker integration, and regulatory compliance. Outputs publication-ready LaTeX/PDF format optimized for drug development, clinical research, and evidence synthesis.
handling-sf-data
IncludedSalesforce data operations with 130-point scoring. Use this skill to create, update, delete, bulk import/export, generate test data, and clean up org records using sf CLI and anonymous Apex. TRIGGER when: user creates test data, performs bulk import/export, uses sf data CLI commands, needs data factory patterns for Apex tests, or needs to seed/clean records in a Salesforce org. DO NOT TRIGGER when: SOQL query writing only (use querying-soql), Apex test execution (use running-apex-tests), or metadata deployment (use deploying-metadata).
accelint-ac-to-playwright
IncludedConvert and validate acceptance criteria for Playwright test automation. Use when user asks to (1) review/evaluate/check if AC are ready for automation, (2) assess if AC can be converted as-is, (3) validate AC quality for Playwright, (4) turn AC into tests, (5) generate tests from acceptance criteria, (6) convert .md bullets or .feature Gherkin files to Playwright specs, (7) create test automation from requirements. Handles both bullet-style markdown and Gherkin syntax with JSON test plan generation and validation.