ce-strategy

Create or maintain STRATEGY.md: what the product is, who it is for, how it succeeds, and where the team is investing.

ce-strategy writes the upstream anchor. STRATEGY.md lives at the repo root next to README.md and is a shared project document. Other tools and people write their own sections into it, so the skill owns only what its template names and leaves the rest alone. It is not a step in /ce-ideate → /ce-brainstorm → /ce-plan → /ce-work. Those skills read STRATEGY.md when it exists and weight their suggestions toward the active tracks and the stated approach. ce-product-pulse also reads it to seed the metrics it measures.

The doc is short on purpose. The skill grounds itself in what the repo already says the product is, asks a few questions, pushes back on slogans and feature lists, and writes what you actually said.

Skip this when you already know the one thing to build. That is ce-ideate (which directions), ce-brainstorm (what this needs to be), ce-plan (guardrails), or ce-work (build it).

/ce-strategy                 /ce-ideate         /ce-brainstorm      /ce-plan             /ce-work
Write the durable            "What's worth      "What does this     "What's needed       "Build it."
anchor, then stay out         exploring?"        need to be?"        to accomplish
of the loop.                                                         this?"

TL;DR

Question Answer
What does it do? Reads what the repo already says the product is, interviews you with pushback rules, stress-tests the answers, then writes or updates STRATEGY.md at the repo root
When to use it New product; adding a strategy doc to an existing repo; direction changed; “what are we working on?” has no written answer; a downstream skill flagged missing strategy grounding
What it produces STRATEGY.md with purpose, positioning, users, 3-5 key metrics, 2-4 tracks, boundaries, and optional milestones and brand. Frontmatter carries name and last_updated.
What’s next /ce-ideate or /ce-brainstorm if nothing downstream has run yet. /ce-product-pulse if you want those metrics measured.

Example invocations

An empty invoke follows the file. A section name or scope hint jumps to that part and leaves the rest untouched.

# No STRATEGY.md yet: interview the required sections, show a draft, offer one edit pass, then write the repo-root file
/ce-strategy

# File already exists: summarize what is on file in 3-5 lines, then ask which section to revisit
/ce-strategy

# Jump to one section. Other sections stay as written.
/ce-strategy positioning
/ce-strategy metrics
/ce-strategy tracks

# Narrower than a whole section
/ce-strategy metrics for retention

# Rewrite the diagnosis after a direction change
/ce-strategy purpose

Prefer a section or scope hint for maintenance. A bare invoke on an existing file asks which section to open.

The Problem

Most teams have no strategy doc, or have one so long nobody opens it.

  • Missing entirely: every new piece of work re-litigates whether you are working on the right thing
  • Slogan, not strategy: “we delight users” gives the agent (and humans) nothing to act on
  • A goal dressed as strategy: “grow ARR by 30%” is a target, not a guiding choice
  • A feature list in place of policy: “we’re building X, Y, and Z” does not say why
  • Written once and left: the doc describes a product the team is no longer building
  • Too long to scan: a 20-page strategy does not get read during day-to-day work

A useful strategy doc is short and opened often. A generic “write a strategy” prompt usually produces prose that hides weak thinking.

The Solution

ce-strategy runs a repo-grounded interview with named pushback rules.

  • It reads the README, CONCEPTS.md, and docs/ first, so the interview opens from a working model of the product instead of a blank page. Recent commits and PRs are read separately, as a signal of where attention has gone lately. That signal informs tracks, not what the product is.
  • Strategy is what the product is and why. Features belong in ce-brainstorm. Schedules belong in the issue tracker.
  • Section headers are plain English. The interview is where the discipline lives.
  • The template is constrained. Extra sections get pushback.
  • Re-runs update in place. Accurate sections stay; weak ones get the same pushback as a first write.
  • Each section has anti-patterns and probe questions that catch slogans, goals-as-strategy, and feature lists.

The Purpose / Positioning / Tracks shape follows Richard Rumelt’s kernel in Good Strategy Bad Strategy: diagnosis, guiding policy, coherent action.

What Makes It Novel

Grounded in the repo, decided by you

Before the first question the skill shows a three-to-five-line repo model with sources named: what it takes the product to be, who it seems to serve, where recent attention has gone. You correct it. Evidence seeds the questions and sharpens the pushback (“the README says X; you just said Y. Which is it?”). It never fills in a section on its own, and a burst of recent work in one area becomes a question about tracks, not a conclusion about the product’s focus. A new or empty repo runs the interview ungrounded. That is a normal path, not a failure.

Pushback in the interview

For each section the skill asks the opening question, then applies that section’s pushback rules. Two rounds maximum. If the answer is still weak, it writes what you gave and notes the section is worth another pass next run. Without that step the interview is just transcription.

Required sections, in the document’s order: Purpose, Positioning, Users, Boundaries (always written, even if only to say nothing is named yet), Key metrics, Tracks. The interview asks Boundaries after the stress test, since that is where its content comes from. Milestones and Brand are optional and skipped when nothing came up; unused optional sections are omitted, not left as empty headers. Metrics stay at 3-5. Tracks stay at 2-4.

On a first run, the filled draft is shown in chat and you get one edit pass before anything is written.

Stress test before the draft

After the five required sections, the skill poses three to five concrete proposals aimed at the draft’s weak points: a tempting feature just off the approach, a second persona pulling the other way, a track that would starve another. They are chosen so your answer is not predictable from the draft. If the strategy already decides a proposal, that confirms it. If it cannot, the approach or a track gets sharpened. Proposals you resist become Boundaries entries and feed a one-line “Resist a change when …” test, so that section carries real content a downstream agent can apply.

Updates in place

A second run does not start over. It reads the existing doc, summarizes it in 3-5 lines, checks for drift against the repo and what has landed since last_updated, and names any stale-looking section as a candidate. Then it jumps to the section you named, or asks which to revisit: Purpose; Positioning; Users; or Metrics, tracks, boundaries, or other. Sections you confirm are still accurate are left alone. last_updated is set to today.

Read by downstream skills

When STRATEGY.md is at the repo root:

  • ce-ideate weights toward strategy-aligned directions
  • ce-brainstorm keeps product and scope decisions on the active tracks
  • ce-plan flags decisions that pull away from the tracks or the stated positioning, or land inside the stated boundaries
  • ce-product-pulse seeds product name and key metrics, then wires sources to measure them

The skills work without the file. With it, they know what kind of work matters right now.

Readers match sections by meaning, not exact heading. ce-ideate, ce-brainstorm, and ce-plan fall back to a legacy PRODUCT.md or VISION.md only for meanings STRATEGY.md lacks. ce-dogfood reads the persona section (Users, or Who it's for in older files), then a legacy sibling. ce-strategy itself reads those files as stated intent when grounding. ce-product-pulse reads STRATEGY.md, or the first of VISION.md and PRODUCT.md when it is absent. It takes metrics from ## Key metrics when ce-strategy wrote it, otherwise from whichever section lists the success measures, following a linked legacy doc when STRATEGY.md defers them there, and says when none are on file yet.

The skill does not compute metric values, update the issue tracker, prioritize a backlog, or write requirements or plans.

Quick Example

You are adding a strategy doc to a repo you have worked in for a year. You run /ce-strategy. No file exists. The skill reads the README and docs, shows a short repo model (“a PR-review tool for engineering teams; recent work is mostly in the GitHub integration”) and asks you to correct it, then starts the interview.

Purpose: you answer “we help teams ship faster.” That is a slogan, so the pushback asks whose teams, shipping what, and what “faster” means. You sharpen to engineering managers at 50-200 person companies cutting PR-review cycle time from days to hours.

Positioning: you answer “use AI.” That is a tool, not a bet. The pushback asks what you are betting AI does here that the obvious alternative does not. You name the actual choice.

The interview continues through Users, Key metrics, and Tracks, where the skill asks whether the recent GitHub work is a track or a push, and you say push. Then three proposals test the draft; you resist one (“a Slack bot for review nudges”), and it lands under Boundaries. You see the full draft, get one edit pass, and the file is written to STRATEGY.md.

The skill notes that ce-ideate, ce-brainstorm, and ce-plan will pick the file up on their next run, and suggests ce-ideate or ce-brainstorm if nothing downstream has run yet.

When to Reach For It

Reach for ce-strategy when:

  • You are starting a product and want an anchor before ideation
  • You are adopting the workflow in an existing repo and want the strategy written down
  • Direction has shifted and the existing file is stale
  • “What are we working on?” keeps coming up because the answer is not written down
  • One section is weak and you want to reopen just that part (/ce-strategy positioning)
  • ce-ideate or ce-brainstorm flagged the missing file as missing grounding

Skip ce-strategy when:

  • The file is on disk and still accurate. Re-running adds noise.
  • You are shaping one feature → /ce-brainstorm
  • You are scheduling work. That is the issue tracker.
  • You want a dated roadmap. Strategy is direction. Sequencing lives elsewhere.

Use as Part of the Workflow

ce-strategy sits above the loop. Recommended sequence on a new product or a major direction change:

/ce-strategy → /ce-ideate → /ce-brainstorm → /ce-plan → /ce-work
                   ↑              ↑              ↑
                   all read STRATEGY.md when it exists

Downstream skills do not require the file. When it exists, the tracks and the positioning pull ideation, brainstorming, and planning toward aligned work. Without it, ce-ideate can still ground in the codebase, but it has no signal for what kind of work matters most right now.

ce-product-pulse seeds its first-run interview from the key metrics in STRATEGY.md.

Use Standalone

This skill is always invoked on its own. Nothing in the loop produces STRATEGY.md.

  • First run: /ce-strategy (no file yet)
  • Targeted update: /ce-strategy positioning jumps to that section
  • Open update: /ce-strategy (file exists, no argument) asks which section to revisit

The sections this skill writes should be readable in under five minutes. Other tools’ sections in the shared file are their own.

Reference

Argument Effect
(empty) No file: full interview, draft in chat, then write. File exists: summarize and ask which section to revisit.
<section name> Jump to that section and preserve the rest. Names include metrics, positioning, tracks, purpose, users, boundaries, plus the optional milestones and brand; older names (approach, target problem, who it's for, not working on, marketing) still resolve.
<scope hint> Focus a revisit, e.g. metrics for retention

Output: STRATEGY.md at the repo root (not under docs/). YAML frontmatter has name and last_updated: YYYY-MM-DD.

Required sections, in order: Purpose, Positioning, Users, Boundaries, Key metrics (3-5), Tracks (2-4). Optional: Milestones (external dates only), Brand. Files written with the older headings are read as-is and renamed in place on the next update. A STRATEGY.md in any other shape (hand-written, or from another tool) is read by meaning and updated in its own shape, never restructured into the template.

FAQ

Why is the doc so short? Long strategy docs are not read. The template forces short answers to a small set of questions. Extra sections usually belong in ce-brainstorm or the issue tracker.

What’s the difference between strategy and a roadmap? Strategy is direction (what you are doing and why). A roadmap is sequencing (what comes when). This skill stays in the strategy lane.

What if my answers are weak? Two rounds of pushback per section, then it records what you gave and marks the section for a later pass. The first write does not have to be final.

Why does the file go at the repo root? So downstream skills can find it without configuration, the same way they find README.md.

What if I don’t want downstream skills to read it? They will if the file exists. That is the point of the anchor. Delete the file to suppress it; you can recreate it later.

Is it useful for a non-software product? The same sections (purpose, positioning, users, metrics, tracks, boundaries) apply to a consulting practice or a non-profit initiative as well as a SaaS product.

Does it compute the current metric values? No. It records which metrics matter and, when you know, where they live. ce-product-pulse is the skill that queries sources.

See Also

  • ce-ideate: reads STRATEGY.md as grounding for ideation
  • ce-brainstorm: reads it for constraint awareness during scope work
  • ce-plan: reads it and flags plan decisions that pull away from active tracks
  • ce-product-pulse: seeds first-run setup from the strategy’s key metrics