# 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.

**Use case**: Write the one-page product strategy that grounds every downstream planning and ideation session

**Canonical URL**: https://agentcookbooks.com/skills/ce-strategy/

**Topics**: claude-code, skills, product-strategy, planning

**Trigger phrases**: "create our STRATEGY.md", "what is our product strategy", "update the strategy doc for the new direction"

**Source**: [Every](https://github.com/EveryInc/compound-engineering-plugin/tree/main/plugins/compound-engineering/skills/ce-strategy)

**License**: MIT

---

## 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](https://github.com/EveryInc/compound-engineering-plugin/tree/main/plugins/compound-engineering/skills/ce-strategy) in [Every's compound-engineering plugin](https://github.com/EveryInc/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](https://github.com/EveryInc/compound-engineering-plugin/tree/main/plugins/compound-engineering/skills/ce-strategy) — 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.