Skill

Pass

Audit score 90

ce-strategy

everyinc/compound-engineering-plugin

Create or update STRATEGY.md to define product purpose, positioning, users, metrics, and investment tracks.

What is ce-strategy?

ce-strategy writes and maintains STRATEGY.md, the repo-root document that captures what the product is, who it serves, how it succeeds, and where the team is investing. Use it when starting a product, adding a strategy doc, or changing direction or roadmap. The file is shared with downstream skills (ce-ideate, ce-brainstorm, ce-plan) that read it for on-strategy work.

Writes STRATEGY.md from scratch via structured interview (Purpose, Positioning, Users, Key Metrics, Tracks, Stress Test, Boundaries, Milestones, Brand)
Updates existing strategy documents while preserving sections not being revisited and respecting multi-writer ownership
Grounds strategy in repo evidence (README, code structure, recent commits) without deriving strategy from code alone
Enforces short, decision-useful strategy by pushing back on expansion and keeping sections focused on what the product is and why
Maintains frontmatter keys and section headings as a contract for downstream skills (ce-ideate, ce-brainstorm, ce-plan, ce-product-pulse, ce-dogfood) to parse
Accepts optional focus hints (e.g., 'metrics' or 'approach') to revisit specific sections in update runs

How to install ce-strategy

npx skills add https://github.com/everyinc/compound-engineering-plugin --skill ce-strategy

Prerequisites

A repo with at least a README or basic product description (optional; works with blank repos)
Access to write STRATEGY.md at the repo root
Familiarity with the product's purpose and intended users (the skill will ask)

Claude Code

Cursor

Windsurf

Cline

How to use ce-strategy

1.Install the skill: npx skills add https://github.com/everyinc/compound-engineering-plugin --skill ce-strategy
2.Invoke with optional focus hint: e.g., 'ce-strategy metrics' to revisit the metrics section, or 'ce-strategy' for open-ended strategy work
3.Answer interview questions one at a time (Purpose, Positioning, Users, Key Metrics, Tracks, Stress Test, Boundaries, and optional sections)
4.Review the draft STRATEGY.md presented in chat and request edits (one round offered)
5.Confirm the final document is written to STRATEGY.md at repo root; downstream skills will read it on their next run

Use cases

Good for

Starting a new product: run Phase 1 interview to establish purpose, positioning, users, key metrics, and investment tracks before brainstorming or planning
Changing product direction or roadmap: update the Tracks or Purpose section while preserving other sections
Adding a strategy doc to an existing repo: ground the document in current README and code structure, then interview to sharpen positioning and metrics
Revisiting a stale section: invoke with a focus hint (e.g., 'metrics') to update only that section in Phase 2
Preparing for downstream work: ensure STRATEGY.md exists and is current so ce-ideate, ce-brainstorm, and ce-plan have grounded context

Who it's for

Product managers and founders defining or refining product strategy
Engineering leads establishing what work is on-strategy vs. scope creep
Teams adopting compound-engineering workflows that depend on a shared STRATEGY.md
Anyone updating strategy without disrupting existing multi-writer documents or losing section ownership

ce-strategy FAQ

What is the difference between Phase 1 (first-run) and Phase 2 (update)?

Phase 1 runs a full interview to create STRATEGY.md from scratch. Phase 2 summarizes the current file, identifies stale sections, and revisits only the section you choose (or the one the focus hint names), preserving all other sections untouched.

Can I use ce-strategy if my repo is brand new with no code yet?

Yes. The skill works with blank repos. It will note that the repo model is ungrounded and proceed with the interview to establish purpose, positioning, and users based on your answers alone.

What happens if STRATEGY.md is written by multiple tools or people?

The skill respects multi-writer ownership. It will not restructure the file into its template format or reorder sections. It edits only the section you ask it to revisit and preserves every other section's content exactly. If a section is marked author-approved, it is never edited.

How do downstream skills use STRATEGY.md?

ce-ideate, ce-brainstorm, ce-plan, ce-product-pulse, and ce-dogfood read STRATEGY.md to ground their work. They parse the frontmatter keys and section headings as a contract, so keeping those consistent is important for the handoff.

What if I want to update only one section, like metrics?

Invoke ce-strategy with a focus hint: 'ce-strategy metrics'. Phase 2 will revisit only that section, ask sharpening questions, and leave all other sections untouched.

Full instructions (SKILL.md)

Source of truth, from everyinc/compound-engineering-plugin.

name: ce-strategy description: "Create or update STRATEGY.md. Use when starting a product, adding a strategy doc, or changing direction or roadmap." argument-hint: "[optional: section to revisit, e.g. 'metrics' or 'approach']"

Product Strategy

The current year is 2026 - use it when dating the document.

ce-strategy writes and maintains its part of STRATEGY.md - the repo-root project document that captures what the project is, who it serves, how it succeeds, and where the team is investing. The file is shared with other tools and people; this skill writes only the sections references/strategy-template.md names. Downstream skills read it when it exists: ce-ideate, ce-brainstorm, and ce-plan for what work is on-strategy; ce-product-pulse for the product name and key metrics; ce-dogfood for the primary persona. Its frontmatter keys and this skill's section headings are the contract those skills parse - keep them for every section this skill authors; a meaning an existing section already carries is merged into it (references/update-run.md).

Done: STRATEGY.md exists at the repo root and the user has seen what will be written and had an edit pass. For a file in this skill's house format, every required section is filled from answers that survived pushback (or explicitly deferred to a linked legacy doc) and the file matches references/strategy-template.md. For a file in any other shape, done is the user-approved minimal edits applied, with the document's shape unchanged. A section the user could not sharpen in two rounds is written as given and named in chat as worth revisiting - a completed run, not a blocked one.

Boundaries

Anchor, not plan. Strategy is what the product is and why. Features belong in ce-brainstorm, schedules and prioritization in the issue tracker, implementation plans in ce-plan; do not let them creep into the doc, and do not update the tracker or reconcile in-flight work.
The user answers; the repo only grounds the question. Use evidence to ask a sharper question, never to fill in a section. Do not derive the strategy from the repo.
Short is a feature. Push back on expansion rather than adding sections.
Record which metrics matter and where they live, not what they read today.
Meaning is the contract; the shape belongs to whoever created the doc. A file that is solely this skill's (references/update-run.md states the test) is maintained in house format on every write: headings renamed, sections in the template's current order, missing required sections offered. Do not treat it as multi-writer merely because the file is shared in principle. A file in any other shape, hand-written or from another tool, is read by meaning and edited in its own shape and idiom: no restructuring into the template, no uninvited frontmatter or headings. Either way, two things are never edited: a section carrying an author-approved marker (e.g. ), and a doc the user does not own. For those, report the conflict, or write a separate file that links to it. A targeted update preserves every other section's content exactly. Where that section sits follows the same ownership test: a solely-owned file takes the template's order; a multi-writer file is never reordered. references/update-run.md defines the rest and is a required read before you edit an existing file.

Asking and routing

Ask one question at a time through the host's blocking question tool already in the current tool list. Match by capability; never probe a user-facing tool to discover it. Fall back to numbered options on the visible chat surface only when no such tool is listed or a real question call errors. Never silently skip the question.

Any argument this skill was invoked with — present in the current prompt or conversation, from the user or a calling skill — is a focus hint: a section to revisit (metrics, positioning, tracks; older names such as approach or who it's for map to the current section) or a scope hint. With none, proceed open-ended and let the file state decide the path.

Phase 0: Ground and route

Phase 0 produces a repo model and a decision about which phase runs next, whatever the harness reads. references/grounding.md is a non-optional load: it carries the full source list and the wording of the disagreement question and the focus hint.

The repo model is your working understanding of what this product is. Read STRATEGY.md if it exists. Take what the product is from its stated intent and structure - README, CONCEPTS.md, docs/, sibling docs such as PRODUCT.md, what the code is organized around - and bound that read to "what is this and who is it for" rather than profiling the whole repo. Take what is getting attention now from recent commits or PRs. Attention informs only the Tracks question and staleness in an update run; where it disagrees with stated intent, that is a question for the user, never a conclusion. Show the model in chat before the first question: three to five lines on what you take the product to be, who it seems to serve, and where attention has gone, each with its source named, and invite correction. If the model did not supply the product's name, ask for it here - the template's frontmatter and title need it. A repo with no substantive content is a normal path: say so in one line and run the interview ungrounded.

The next phase is announced in one line by file state: no file -> Phase 1 ("Strategy doc not found - let's write it."), after the legacy-sibling offer in references/grounding.md when one applies; file exists -> Phase 2 ("Found existing strategy - let's review and update.").

Phase 1: First-run interview

Read references/interview.md before the first question - a non-optional load. The opening questions, pushback rules, anti-pattern examples, quality bar, blocking-question tool per host, and the two-round cap live there; improvising from memory produces a passive transcription instead of a strategy doc.

Run the interview in this order (the document itself follows the template's order; Boundaries is asked after the stress test, where its content comes from):

Purpose
Positioning
Users
Key metrics
Tracks
Stress test
Boundaries (always written)
Milestones (optional)
Brand (optional)

When every section is captured, read references/strategy-template.md, fill it in, present the full draft in chat, offer one round of edits, then write STRATEGY.md.

Phase 2: Update run

Read references/update-run.md first - a non-optional load, before the summary, the drift check, or any question. It decides how drift candidates are raised, which section is revisited, and what is preserved untouched. An update run summarizes the file's current state in 3-5 lines, and names any section the repo model suggests is stale as a candidate rather than a verdict. It then revisits the section the focus hint named, or the one the user picks when asked. The user may pick any section; list the drift candidates first, as suggestions rather than as the only choices. Every other section's content is left untouched, and its place follows the ownership test in references/update-run.md. Questions and pushback still come from references/interview.md, applied as if this were a first run.

Phase 3: Downstream handoff

Note in one line where the file lives and that ce-ideate, ce-brainstorm, and ce-plan pick it up as grounding on their next run. If no downstream skill has run here yet, suggest ce-ideate or ce-brainstorm as a next step.