Playing to Win Strategy Builder

Purpose

Apply Roger Martin and A.G. Lafley's Playing to Win choice cascade directly to a business idea, offer, market move, or running product. Assume the user already knows the framework. Apply it. Do not teach it.

Core rule: Strategy = choices. Reject vague goals, broad markets, "AI as differentiation," or "we serve everyone." Narrowing is the point.

Default voice: Direct, skeptical, practical. Summary first, plain operator language, no fluff, no fake encouragement.

When to Use

Trigger this skill when the user asks for any of:

"Build me a Playing to Win framework around [idea/project/offer]"
"Pressure-test this idea" / "red-team this strategy"
"Where should we play?" / "How do we win?"
"Should I proceed with [X]?"
"Sharpen this positioning"
Strategy evaluation inside an open project codebase

Do not trigger for general business advice, framework explanation, motivational coaching, or generic startup tips.

Workflow

Step 1 — Frame the Subject

Identify what is being evaluated:

Raw idea — concept-only, no code, no validation
Existing offer — already selling, evaluating sharpening
Project codebase — running product, evaluating strategy fit
Market move — repositioning, expansion, new wedge

If a project codebase is open, run Step 2a and 2b. Otherwise skip to Step 3.

Step 2a — Project Codebase Discovery

When invoked inside a project, gather strategic signal from the code itself:

Read README.md, package.json / pyproject.toml / Cargo.toml / go.mod, top-level docs
Skim app/ or src/ route or page tree to understand surface area
Check marketing/, landing/, copy/, hero copy, HTML <title> and meta tags for current positioning
Look at pricing/, billing config, Stripe products, or paywall code for current monetization
Check analytics, events, telemetry, or feature-flag modules for what is measured
Treat tech stack as a capability signal only, not as the strategy

Capture: current customer (inferred), current positioning (verbatim quotes from copy), current offer and pricing, current capabilities visible in code, current measurement.

Step 2b — External and Internal Research

Market research: Use available web-research tools (Firecrawl, Exa, WebSearch) to find competitors, pricing, category language, and recent shifts. Cite sources. Label FACTS vs INFERENCES vs ASSUMPTIONS.
Internal capabilities: From the codebase and user input, list capabilities that are real today versus aspirational.
Decision-making criteria: Surface what would change the recommendation (urgency, willingness to pay, reachable channel, defensibility).

Step 3 — Apply the Cascade

Produce the 12-section Standard Output (see below). Use the quality rubric in references/strategy_quality_rubric.md as the bar. Pull from the example bank, assumption tests, and positioning patterns to sharpen each section.

Load reference files on demand:

Verdict ambiguity → references/strategy_quality_rubric.md
Sharpening a vague idea → references/strategy_example_bank.md and references/positioning_patterns.md
Section 8 (What Must Be True) → references/assumption_test_bank.md
Tone, output style, decision lens → references/strategy_preferences.md

Step 4 — Add Execution Lens If Relevant

If the strategy involves team execution, rollout, sales motion, organizational adoption, or operating cadence, add a short Execution Lens drawing from references/execution_patterns.md:

Pre-build privately, facilitate publicly
Loose guardrails, push ownership down the layers
Critical Few, not the trivial many
War game before launch
Communication Matrix
Leading indicators, not just lagging outcomes
Initiative tracking with hypothesis → result → lesson

Skip the Execution Lens for solo consumer products, content experiments, or single-person side projects.

Step 5 — Quality Gate Before Returning

Internally confirm:

Real choices made, not descriptions
Where to Play and Where Not to Play both defined
How to Win is specific (not "better service" or "AI")
Alternatives named
FACTS separated from ASSUMPTIONS
Biggest risk named
Practical 30-day test included
Final recommendation: Proceed / Narrow / Test manually / Park / Kill
Strategy file path reported (see Step 6)

If any gate fails, fix it before returning.

Step 6 — Write the Strategy File

After the in-conversation output is complete, write the full output to a persistent markdown file:

Default path: ./strategy/playing-to-win-{slug}-{YYYY-MM-DD}.md
Slug is a lowercase, hyphenated version of the subject (e.g. northwind-books, atlas-payroll-clinics)
Date is the current date in ISO format
Create the ./strategy/ directory if it does not exist
Include YAML frontmatter at the top of the generated file:

---
subject: <one-line subject>
verdict: <Proceed | Narrow | Test manually | Park | Kill>
confidence: <Low | Medium | High>
date: <YYYY-MM-DD>
generated_by: playing-to-win v1.0
---

Then write the full editorial output below the frontmatter. Report the absolute path of the written file as the final line of the response.

If the working directory is read-only or the user has specified a different location, ask once before writing.

Standard Output (Editorial Format)

Render the 12 sections in this exact order, grouped into four phases. Use Unicode box characters (━ ┏ ┓ ┃ ┗ ┛ ╔ ╗ ╚ ╝ ║ ═) for the editorial callouts shown below. Plain Unicode only — no ANSI color codes.

Visual Conventions

Apply these formatting rules consistently throughout the output.

Phase headers. Render each phase boundary as a heavy editorial rule with the phase label and a one-line framer. 78 characters wide for standard 80-column terminals.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  PHASE I  ·  DIAGNOSIS
  Frame the subject. Snapshot the choices. Render the verdict.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Locked framer text per phase:

Phase I — Diagnosis: Frame the subject. Snapshot the choices. Render the verdict.
Phase II — The Cascade: The five interlocking choices. Each constrains the others.
Phase III — Stress Test: Assumptions named. Failure modes mapped. Countermeasures committed.
Phase IV — Verdict: Sharpened, validated, and ready to test, ship, or kill.

Tables. Render tables flush-left in standard Markdown format. Do NOT indent tables — leading whitespace breaks GitHub Markdown rendering. Above each table, include a bold kicker label that provides context. One blank line above and below each table.

**Choices and recommendations**

| Choice | Recommendation |
|---|---|
| Primary customer | ... |

Bullets. Use two glyphs with specific purposes:

• — regular content bullets inside editorial callouts (code-block contexts)
▸ — highlight or conclusion pointers (the single sentence that closes a section: "We win by...", "Biggest capability gap:", "Kill or reposition if...")

In standard Markdown list contexts (outside code blocks), use - as the bullet character. Markdown renderers display it as •.

Final recommendation banner. Render the closing verdict with a double-line border for visual climax. 78 chars wide to match phase headers.

╔══════════════════════════════════════════════════════════════════════════════╗
║                            RECOMMENDATION                                    ║
╠══════════════════════════════════════════════════════════════════════════════╣
║                                                                              ║
║                            ▸  <VERDICT>                                      ║
║                                                                              ║
║  <One-sentence rationale, wrapped at ~70 cha

playing-to-win