Specify

Capture feature intent and acceptance criteria before planning begins. Writes docs/specs/<YY_MM_DD_HH>_<name>/spec.md and stops — the user must approve the spec before the plan skill runs.

Doc paths

Default convention: specs live under docs/specs/. Check the project's CLAUDE.md for an overriding location (e.g. a "Docs Layout" section or explicit mention of spec paths) before falling back to the default.

Spec Identifier Derivation

1. Use Glob with pattern docs/specs/*/*.md to list existing spec folders — do NOT use a trailing-slash pattern (docs/specs/*/) or a bare docs/specs/*, both silently return nothing on Windows; the nested */*.md form matches files one level down and works
2. Generate the current local timestamp as YY_MM_DD_HH (for example, 26_07_18_14)
3. Combine it with a short kebab-case feature name: <YY_MM_DD_HH>_<name>
4. Do not derive or assign a numeric index

Orchestration

Spawn an architect sub-agent (general-purpose) briefed with:

• The user's feature description
• Relevant project rules from CLAUDE.md and any project rules directory
• The output path: docs/specs/<YY_MM_DD_HH>_<name>/spec.md
• The spec format below

The architect writes the spec file directly. You (orchestrator) then:

1. Present the spec contents to the user
2. Collect feedback and re-brief the architect if changes are needed (iterate until the user approves)
3. Stop. Do not run the plan skill or write any code. The user must explicitly request the next step.

Spec Format

# Spec: <Feature Name>

## Feature Intent

As a <role>, I want <capability>, so that <benefit>.

## Acceptance Criteria

Legend: `Precondition => Action => Outcome`, grouped under a shared precondition where one applies to several rows.

- <Precondition or scenario shared by the rows below>
  - <action> => <outcome>
  - <action> => <outcome>
- <Next precondition or scenario group>
  - <action> => <outcome>
- (cover the happy path and the most important edge cases; a group can hold a single row if nothing else shares its precondition)

## Tech Notes

Maps each product-facing behaviour above to its concrete implementation — specific files, classes, methods, commands, state paths.

- <Acceptance-criteria bullet or group, restated briefly>:
  - <implementation detail>
  - <implementation detail>

## Out of Scope

- (explicit exclusions — things the feature deliberately will not do)

## Ambiguities

- [NEEDS CLARIFICATION: <question the architect cannot resolve from context alone>]
- (omit this section entirely if there are no ambiguities)

Rules

• Do NOT write any plan, code, or assets — only the spec document.
• Acceptance Criteria stays in plain product language — describe what the player/user does and sees (e.g. "Player clicks a province"), never which class, method, or command fires. Group rows that share a precondition under one bullet instead of repeating it per row — this is what keeps the section skimmable instead of a wall of near-duplicate lines.
• Tech Notes carries every technical anchor the architect would otherwise cram into Acceptance Criteria: exact class/method names, command types, state paths, file references. One entry per Acceptance Criteria bullet/group that needs one; omit Tech Notes entries for purely product-level bullets that need no technical grounding.
• Use [NEEDS CLARIFICATION: …] markers freely — surfacing unknowns early is the point.
• The spec folder name starts with its creation timestamp and uses a kebab-case name: docs/specs/26_07_18_14_my-feature/spec.md.
• Do not create plan.md in the spec folder — that is the plan skill's job.