Spec Strategy

Product Strategy

Note: Use the current date from the active host context. Use this when weighting external sources and dating artifacts.

spec-strategy produces and maintains STRATEGY.md - a short, durable anchor document that captures what the product is, who it serves, how it succeeds, and where the team is investing. It lives at the repo root as a canonical, well-known file (peer of README.md). Downstream skills (spec-ideate, spec-brainstorm, spec-plan) read it as grounding when it exists.

The document is short and structured on purpose. Good answers to a handful of sharp questions produce a better strategy than any amount of prose. This skill asks those questions, pushes back on weak answers, and writes the doc.

Interaction Method

Default to 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. Fall back to numbered options in chat only when no blocking tool exists in the harness or the call errors (e.g., Codex edit modes) — not because a schema load is required. Never silently skip the question.

Ask one question at a time. Prefer free-form responses for the substantive sections (problem, approach, persona); reserve single-select for routing decisions (which section to revisit). Each option label must be self-contained.

Focus Hint

Interpret the user's current request as an optional focus: a section name to revisit (metrics, approach, tracks) or a scope hint. With no focus, proceed open-ended and let the file state decide the path.

Core Principles

1. Anchor, not plan. Strategy is what the product is and why. Features belong in spec-brainstorm; schedules belong in the issue tracker. Do not let either creep into the doc. When declining such creep, name the destination explicitly (spec-brainstorm for features, the issue tracker for schedules) — a bare refusal or a generic "put it elsewhere" leaves the owner without a route.
2. Rigor in the questions, not the headings. The section headers are plain English. The interview questions enforce strategy discipline.
3. Short is a feature. The template is constrained. Adding sections costs more than it looks like. Push back on expansion.
4. Durable across runs. This skill is rerunnable. On a second run it updates in place, preserves what is working, and only challenges sections that look stale or weak.

Execution Flow

Phase 0: Route by File State

Read STRATEGY.md using the native file-read tool.

• File does not exist -> First run. Go to Phase 1.
• File exists and argument names a specific section -> Targeted update. Go to Phase 2.
• File exists, no argument -> Ask which section(s) to revisit, then Phase 2.

Announce the path in one line: "Strategy doc not found - let's write it." or "Found existing strategy - let's review and update."

Phase 1: First-Run Interview

Read references/interview.md. This load is non-optional - the pushback rules, anti-pattern examples, and quality bar for each section live there. Improvising from memory produces a passive transcription instead of a strategy doc.

Run the interview in the section order of the final document:

1. Target problem
2. Our approach
3. Who it's for
4. Key metrics
5. Tracks
6. Milestones (optional)
7. Not working on (optional)
8. Marketing (optional)

For each section, ask the opening question, apply the pushback rules, and capture the final answer in the user's own language. Do not skip the pushback step - it is the core of the skill. Two rounds of pushback per section maximum; capture what the user has given after that and note the section is worth revisiting on the next run.

When all required sections (1-5) are captured, read references/strategy-template.md, fill it in, and present the full draft in chat before writing. Offer one round of edits. Then write to STRATEGY.md.