ce-strategy
A skill from Every's compound-engineering plugin that creates and maintains `STRATEGY.md` — a short, durable anchor doc at the repo root capturing the product's target problem, approach, audience, key metrics, and work tracks. It runs a structured interview that pushes back on weak answers, treats strategy as Rumelt's 'diagnosis, guiding policy, coherent action,' and is rerunnable: updating individual sections while preserving solid existing content.
Write the one-page product strategy that grounds every downstream planning and ideation session
Trigger phrases
Phrases that activate this skill when typed to Claude Code:
create our STRATEGY.mdwhat is our product strategyupdate the strategy doc for the new direction
What it does
ce-strategy creates and maintains STRATEGY.md, a concise anchor document that lives at the repo root alongside README.md — see skills/ce-strategy in Every’s compound-engineering plugin. It captures what the product solves, who uses it, how success is measured, and where the team is investing effort. The document has five required sections — target problem, approach, audience, key metrics, and work tracks — plus optional sections for milestones, out-of-scope items, and marketing notes.
It runs a structured interview that pushes back on weak answers, then produces a short, durable doc rather than a sprawling planning artifact. It’s rerunnable: on later uses it updates specific sections while preserving solid existing content. The underlying philosophy treats strategy as “diagnosis, guiding policy, and coherent action” — not a feature list and not a schedule. In the plugin’s loop, ce-strategy is the upstream anchor: it’s the grounding that ce-ideate and ce-plan read from before any feature work, and the baseline that ce-product-pulse measures against downstream.
When to use it
- Launching a new product, or starting a repo that will grow — write the one-pager before the feature backlog
- A direction shift — rerun to update approach / metrics without rewriting the whole document
- Before a planning or ideation session that needs grounding (the doc is designed to be that upstream input)
- When the team can’t agree on what success means — the key-metrics interview forces the question
When not to reach for it:
- A throwaway script or short-lived spike where strategy is overhead
- Marketing positioning and messaging — that’s a different concern; this is product strategy (problem, approach, metrics)
- Sprint planning or scheduling — strategy here is “guiding policy,” not the calendar
Install
Part of the compound-engineering plugin (not a standalone ~/.claude/skills/ drop-in). In Claude Code:
/plugin marketplace add EveryInc/compound-engineering-plugin
/plugin install compound-engineering
Then invoke /ce-strategy to create or update STRATEGY.md. The plugin namespaces every skill with ce-. MIT-licensed.
What a session looks like
- Invoke
/ce-strategyon a new repo. - Interview, with pushback. “What’s the target problem?” You answer vaguely — “help teams work better” — and the skill pushes back, asking for the specific job and who has it.
- Approach and audience get the same treatment: diagnosis before policy, no platitudes.
- Key metrics. It forces a small set of real success measures, not vanity counts.
- Work tracks. The current bets — where effort is actually going.
- It writes
STRATEGY.mdat the repo root. Optional sections (milestones, out-of-scope, marketing notes) appear only if relevant. - Months later, you pivot the audience. Rerun: it updates the audience and approach sections and leaves the rest intact.
The discipline that makes it work: it refuses weak answers. A strategy doc full of platitudes is worse than none, because downstream skills will faithfully ground themselves in mush — the pushback during the interview is the part that makes the output durable.
Receipts
TODO — to be filled in from a real session. Once STRATEGY.md has been generated and lived with on a real project, this section will capture: whether the interview’s pushback actually sharpened a vague problem statement, how the five sections held up as the product evolved, whether downstream skills (ce-plan, ce-product-pulse) meaningfully read from the doc, and whether a rerun cleanly updated sections without clobbering good content.
Source and attribution
From Every’s compound-engineering plugin — the MIT-licensed plugin (Dan Shipper & Kieran Klaassen) packaging Every’s engineering workflow.
License: MIT.
Quoting the framing verbatim: strategy as “diagnosis, guiding policy, and coherent action” — Richard Rumelt’s definition, which the skill uses to keep STRATEGY.md from degrading into a feature list or a schedule.