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 owns 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. Evidence earns a sharper question, never fills 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, 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 a section carrying an author-approved marker (e.g. ), or a doc the user does not own, is not edited at all - report the conflict, or write a separate file that links to it - and a targeted update preserves every other section's content exactly, its place following that ownership test (a solely-owned file takes the template's order; a multi-writer file is never reordered). references/update-run.md owns the rest and is a required read before you edit an existing file.

Asking and routing

Ask one question at a time, through the platform's blocking question tool: AskUserQuestion in Claude Code (call ToolSearch with select:AskUserQuestion first if its schema isn't loaded), request_user_input in Codex, ask_question in Antigravity CLI (agy), ask_user in Pi (needs the pi-ask-user extension). Fall back to numbered options on the host's user-visible chat surface only when no blocking tool exists or the call errors (e.g., Codex edit modes) — not because a schema load is required. Never silently skip the question.