Skip to main content

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

Source Every
License MIT
First documented
Receipts TODO

Trigger phrases

Phrases that activate this skill when typed to Claude Code:

  • create our STRATEGY.md
  • what is our product strategy
  • update 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

  1. Invoke /ce-strategy on a new repo.
  2. 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.
  3. Approach and audience get the same treatment: diagnosis before policy, no platitudes.
  4. Key metrics. It forces a small set of real success measures, not vanity counts.
  5. Work tracks. The current bets — where effort is actually going.
  6. It writes STRATEGY.md at the repo root. Optional sections (milestones, out-of-scope, marketing notes) appear only if relevant.
  7. 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.