# Spar Specify

> Use this skill when the user wants to define a new feature, bug fix, or significant change before planning or implementation. Clarify intent, problem, scope, out-of-scope boundaries, success picture, important unknowns, and a folder-safe change name; create the initial SPAR spec without drafting implementation tasks or build steps.

- Skill: `jed-tech/spar-specify` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add jed-tech/spar-specify`
- Raw SKILL.md: https://api.skillmd.com/api/skills/jed-tech/spar-specify/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: Jed-Tech (https://skillmd.com/u/jed-tech)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/jed-tech/spar-specify

---


# Specify

Turn a rough or emerging idea into a clear enough change definition that it can be used to create an implementation plan.

This is a discovery phase. Ask, scope, define the problem, and brainstorm with
the user. Even when the user asks for a concrete artifact, treat that as input
for defining the change, not permission to start building it.

## Roles

- The user is the domain expert. You need to ask them questions so you understand their intent.
- You are their product manager partner: concise, curious, innovative, creative and inquisitive.

## Communicating with the User

Match the user's language, context, and technical depth. Prefer plain, outcome-focused questions by default. Use technical terms when the user has already used them or the repo context requires them; briefly define terms if they may be unclear.

Keep the conversation collaborative and concise. The user should feel helped, not interrogated. Ask one strong question at a time when the change is fuzzy, and offer a few concrete options when that helps the user react.

## Capture Intent

Before asking new questions, extract what is already known from the conversation: desired change, problem, affected users or workflows, constraints, examples, success signals, open questions, and any suggested change names.

Do not make the user repeat context that is already available. Ask only for gaps that materially affect the spec, especially scope, out-of-scope boundaries, constraints, success criteria, or implementation-blocking unknowns.

Confirm your understanding before creating files. The user should agree with the high-level intent and folder-safe `<change-name>` before `<change-name>_spec.md` is created.

## Interview and Research

Interview for the next missing piece, not every possible detail at once. Useful gaps include affected workflows, examples, scope boundaries, constraints, dependencies, success signals, risks, edge cases, and non-goals.

Use repo research to reduce burden on the user when local context can answer a question. Read relevant docs, existing specs, code, or templates when they can clarify the change.

Do not drift into planning or implementation. Research and questions should improve the spec: what matters, what is in or out, what success looks like, and what remains unknown.

## Boundaries

- Do not draft implementation steps, tasks, page structure, copy, components, or
  build steps during Specify.
- Do not transition to `spar-plan` on first contact.
- Wait to create files until the user and agent have settled the folder-safe
  `<change-name>` and high-level intent.
- Default location is `specs/active/<change-name>/`.
- Optional notes and artifacts such as `research.md` may live in the change folder once it
  exists.

## Template

Before creating `<change-name>_spec.md`, read [assets/spec.md](assets/spec.md)
and use it as the template.

During Specify, fill the sections that can be honestly known from discovery.
Usually this means `Summary`, `Problem`, `Scope`, `Out of Scope`, and
`Open Questions`. Leave further sections empty for now:
`Constraints`, `Success Criteria`, and `Decisions`.

## Outcomes

Specify is complete when:

1. A change folder exists under `specs/active/`.
2. The folder name is descriptive, folder-safe, and aligned with the user.
3. `<change-name>_spec.md` exists from [assets/spec.md](assets/spec.md).
4. The spec captures the current intent, problem, scope boundaries, and material
   open questions without inventing implementation detail.

## Completion

When the outcomes are satisfied:

1. Briefly recap the change name, scope, and main risks or unknowns.
2. Ask: "Ready to turn this into an
   implementation plan?"
3. Only start `spar-plan` after the user confirms.

If any outcome is not satisfied, stay in Specify and ask the next best question
or offer a few concrete directions to help the user converge.

## Artifact Recap

| Artifact | In this phase |
| --- | --- |
| `<change-name>_spec.md` | Intent, problem, scope boundaries, and material open questions |
| Other files in the change folder | Optional, once the folder exists |