ce-strategy

• SKILL.mdcore · 7,592 bytes
• SKILL.mdcore · 7,592 bytes
• SKILL.mdcore · 7,592 bytes
• references/grounding.mddoc · 3,277 bytes
• references/interview.mddoc · 16,145 bytes
• references/strategy-template.mddoc · 4,610 bytes
• references/update-run.mddoc · 5,589 bytes

# Product Strategy

`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. `<!-- <tool>: author-approved 2026-07-10 -->`), 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.