2. Make decisions

/create-spec

Explore the code first, ask only what’s left.

Install this skill Read the skill and templates

When to use it

Your brainstorm is clear enough to turn into concrete requirements.
A new product needs a shared plan for its architecture and constraints.
A change to an existing product needs focused scope and acceptance criteria.

How it works

brainstorm_<name>.md or decision_<name>.md
an issue or a request
your codebase code, manifests, docs, schema, deploy config, .env.example names

/create-spec explores before it asks

Answered by the codebase most questions: the stack, existing patterns and behavior, schema, deploy setup
Interviews you only what the code can’t answer, with a recommended answer

the spec project_spec.md or feature_spec_<name>.md

1 Explore first
Reads the brainstorm or decision doc, the issue, and the code, docs, schema and config.
2 Ask only the rest
What the code can’t answer and that changes scope, each with a recommended answer.
3 Pick the spec
Project spec for a big project. Feature spec for a feature.
4 Fill in the template
Verification: Success and Proof, and open questions, always.
5 Save it
project_spec.md or feature_spec_<name>.md, source linked at the top.
6 Finish
Scope, assumptions, open decisions. Offers to research “(research needed)” items.

What you get

project_spec.md for a new product or large initiative, or feature_spec_<name>.md for a change to something that exists. Every spec defines Verification: Success and Proof and lists its assumptions and open questions.

For a big project

/brainstorm
/create-spec
project_spec.md

For a feature

an issue or brainstorm + the code it changes
/create-spec
feature_spec_<name>.md

project_spec.md

Overview: what it is, who it’s for, why
1. Product requirements: who it’s for and the job to be done, problems, key user flows, UI/UX, scope and milestones (MVP, deferred, out of scope, V2, future)
2. Engineering requirements: tech stack, architecture, data model, external services and setup, research needed
3. Verification: Success and Proof: successful outcome, criteria table, end-to-end proof, constraints
Assumptions and open questions
What agents should ask you

feature_spec_<name>.md

Overview: what the feature does and why
1. Product requirements: who it’s for and the job to be done, requirements, UI/UX, edge cases, out of scope
2. Engineering requirements: scope of changes (confirmed or inferred), data, API and dependency changes, external services and setup
3. Verification: Success and Proof: the same, plus rows for existing behavior the change could break
Assumptions and open questions
What agents should ask you

Next step

When it’s done, /create-spec recommends one of these:

Build from the spec · v1 fits one build session
/create-issues · v1 doesn’t fit one session
Backlog the rest · built straight from the spec? later milestones become issues

Install /create-spec

One prompt installs just this skill and its templates. Want the whole system? Install all five from the Planning System page.

Then paste it into a conversation with your agent.

Works with

Claude Code
Codex
Grok Bot

Download create-spec.zip Unzip into your agent’s skills folder.

Read the installation prompt

Install the create-spec skill from this manifest for use in the agent I am using now:
https://ainativebuilder.com/plan/resources/create-spec/manifest.json

Identify this agent and use its supported personal/global skill installation or saved-skill mechanism, so the skill is reusable beyond the current project or conversation. If the correct mechanism is unclear, check this agent's official instructions before proceeding.

Fetch the manifest and download every listed file from the same origin. Preserve the exact contents and relative references of all 3 Markdown files, keeping each skill in its own folder named after the skill. Stage the complete bundle and verify its SHA-256 hashes before installation. If a download or hash check fails, stop and report it without changing existing skills. Back up any existing same-name skills before replacing them; keep filesystem backups outside skill-discovery directories. Install independent copies, not symlinks.

Verify that the skill is saved and discoverable and that every referenced template is accessible. If this host cannot preserve the complete bundle, explain the limitation instead of claiming successful installation. Report any enablement or refresh step still needed.

Confirm what was installed and where, then stop. Do not invoke the skill, start an interview, plan a project, or implement anything.

Install all five skills instead

Full instructions & templates

Read each complete file below. Copy or download the original Markdown to use with your agent.

Create spec skill

create-spec/SKILL.md

Select and copy the complete source below.

---
name: create-spec
description: Create an actionable product and engineering spec from an idea, planning document, or GitHub or Linear issue. Use when the user asks for a spec or PRD.
---

# Create Spec

Produce a working spec grounded in the user's goal and what already exists in the repository. A **project spec** covers a new product or large initiative; a **feature spec** covers a change to something that exists. Pick by the size of the work, not by whether the input was a file or an issue.

## Gather context

- Input is the current request plus any invocation text: an inline idea, a local file to read, or an issue. Fetch issues through an available GitHub or Linear connector, or `gh issue view <number> --repo <owner/repo>`. If you can't reach the issue, ask for its content rather than guessing.
- Check the planning folder (`plans/`, `specs/`, or `docs/specs/`) for a related `brainstorm_<name>.md` or `decision_<name>.md`. Treat it as input and ask only about what it leaves open.
- Look at the relevant code, manifests, docs, schema, and deployment config before asking anything those can answer. Read `.env.example` and variable names, never secret values.
- For a change to existing code, `blast-radius` (if available) maps the areas it touches and the existing behavior at risk; use its findings for Scope of Changes and the at-risk verification rows.
- For a new project with no stack preference, recommend one that fits the project and mark uncertain choices **(research needed)**; verify time-sensitive choices before recommending them.

## Ask only what matters

Ask about decisions that materially change scope or implementation and that the input and codebase don't settle: who it's for and the problem, what v1 must do and must not, how success is observed, acceptance criteria and edge cases, stack or deployment constraints, and which technical choices need research. Recommend an answer for each question when the evidence supports one, and label assumptions as assumptions. A well-specified issue may need no interview at all. Use a structured question tool if the host has one; plain conversation is fine.

## Write the spec

Fill in [project_spec_template.md](references/project_spec_template.md) or [feature_spec_template.md](references/feature_spec_template.md); the template defines the sections. Drop sections that don't apply, mark real unknowns explicitly, and don't invent milestones to fill the template. Distinguish observed repository facts from inferred scope or proposed architecture. Record a deadline the user gave as a constraint; don't add a schedule or interim dates unless asked.

Whatever the template contains, every spec must define **Verification: Success and Proof** and list its **assumptions and open questions**. Verification means the observable successful outcome, criteria paired with suitable verification methods and explicit passing results, and end-to-end proof of the main user journey: exercised through the real user path rather than internal shortcuts or test-only endpoints, with how an agent will drive the app (browser, terminal, HTTP calls) and the side effects to confirm, such as saved records, files written, or messages sent. Include important failure cases, checks for specific existing behavior the change could break, and any verification constraints when relevant. Keep checks proportional to the work. Distinguish planned verification from actual results; writing the spec does not establish that any check has passed. Identify criteria that would remain unverified when access, credentials, user review, or observation time is unavailable.

Keep it concise: this is a working document, not a formal PRD.

Name it `project_spec.md` or `feature_spec_<name>.md` and link its source (brainstorm doc, issue, or request) at the top. Save it where the user says. Otherwise use the project's existing planning folder (`plans/`, `specs/`, or `docs/specs/`), or create `plans/` at the project root. Don't overwrite an existing spec unless asked to revise it.

## Finish

Link the saved spec, summarize its scope, key assumptions, and open decisions, and apply any revisions the user asks for. Offer to research the **(research needed)** items.

Then recommend a next step:

- **v1 fits in one build session** → offer to build it from the spec, working until its Verification: Success and Proof checks pass, or reporting which remain unverified and why.
- **It doesn't** → split it into issues (with `create-issues` if available) and build them one at a time.
- **Project built straight from the spec** → offer to turn the later milestones into issues as a backlog.

Continue only when the user says so or asked for it up front.

Create Spec

Produce a working spec grounded in the user’s goal and what already exists in the repository. A project spec covers a new product or large initiative; a feature spec covers a change to something that exists. Pick by the size of the work, not by whether the input was a file or an issue.

Gather context

Input is the current request plus any invocation text: an inline idea, a local file to read, or an issue. Fetch issues through an available GitHub or Linear connector, or gh issue view <number> --repo <owner/repo>. If you can’t reach the issue, ask for its content rather than guessing.
Check the planning folder (plans/, specs/, or docs/specs/) for a related brainstorm_<name>.md or decision_<name>.md. Treat it as input and ask only about what it leaves open.
Look at the relevant code, manifests, docs, schema, and deployment config before asking anything those can answer. Read .env.example and variable names, never secret values.
For a change to existing code, blast-radius (if available) maps the areas it touches and the existing behavior at risk; use its findings for Scope of Changes and the at-risk verification rows.
For a new project with no stack preference, recommend one that fits the project and mark uncertain choices (research needed); verify time-sensitive choices before recommending them.

Ask only what matters

Ask about decisions that materially change scope or implementation and that the input and codebase don’t settle: who it’s for and the problem, what v1 must do and must not, how success is observed, acceptance criteria and edge cases, stack or deployment constraints, and which technical choices need research. Recommend an answer for each question when the evidence supports one, and label assumptions as assumptions. A well-specified issue may need no interview at all. Use a structured question tool if the host has one; plain conversation is fine.

Write the spec

Fill in project_spec_template.md or feature_spec_template.md; the template defines the sections. Drop sections that don’t apply, mark real unknowns explicitly, and don’t invent milestones to fill the template. Distinguish observed repository facts from inferred scope or proposed architecture. Record a deadline the user gave as a constraint; don’t add a schedule or interim dates unless asked.

Whatever the template contains, every spec must define Verification: Success and Proof and list its assumptions and open questions. Verification means the observable successful outcome, criteria paired with suitable verification methods and explicit passing results, and end-to-end proof of the main user journey: exercised through the real user path rather than internal shortcuts or test-only endpoints, with how an agent will drive the app (browser, terminal, HTTP calls) and the side effects to confirm, such as saved records, files written, or messages sent. Include important failure cases, checks for specific existing behavior the change could break, and any verification constraints when relevant. Keep checks proportional to the work. Distinguish planned verification from actual results; writing the spec does not establish that any check has passed. Identify criteria that would remain unverified when access, credentials, user review, or observation time is unavailable.

Keep it concise: this is a working document, not a formal PRD.

Name it project_spec.md or feature_spec_<name>.md and link its source (brainstorm doc, issue, or request) at the top. Save it where the user says. Otherwise use the project’s existing planning folder (plans/, specs/, or docs/specs/), or create plans/ at the project root. Don’t overwrite an existing spec unless asked to revise it.

Finish

Link the saved spec, summarize its scope, key assumptions, and open decisions, and apply any revisions the user asks for. Offer to research the (research needed) items.

Then recommend a next step:

v1 fits in one build session → offer to build it from the spec, working until its Verification: Success and Proof checks pass, or reporting which remain unverified and why.
It doesn’t → split it into issues (with create-issues if available) and build them one at a time.
Project built straight from the spec → offer to turn the later milestones into issues as a backlog.

Continue only when the user says so or asked for it up front.

Project spec template

create-spec/references/project_spec_template.md

Select and copy the complete source below.

# Project Spec: [Name]

**Source:** [brainstorm doc, issue, or request]
**Date:** [YYYY-MM-DD]
**Deadline:** [Date and why, if there is one]

## Overview
**Type:** [internal tool / personal project / public product / MVP / learning project]

> [1-2 sentences: what it is, who it's for, and why it's being built]

---

## 1. Product Requirements

### Who it's for and the job to be done
- **Target user:** [Specific user description]
- **Job to be done:** When [situation], they want to [motivation], so they can [outcome].

### Problems it solves
- [Problem]

### Key user flows
- [Flow, step by step at a high level]

### UI/UX
_Screens or surfaces, look and feel (with reference apps), and accessibility or usability needs._

- [Screen, interaction, or design reference]

### Scope and milestones

**MVP (Milestone 1):** the minimum needed to validate the idea.
- [Feature]

**Deferred (not in the MVP, may come later):**
- [Item planned for V2 or later]

**Out of scope (not part of this project):**
- [Explicit exclusion]

**V2 (Milestone 2):**
- [Feature]

**Future versions:**
- [Idea for later]

---

## 2. Engineering Requirements
_Record the decisions that are expensive to reverse or need the user: stack, architecture, data model, outside services and setup, and anything the user wants to review before code exists. Leave implementation detail, such as full schemas and API endpoints, to build time._

### Tech Stack
| Layer | Choice | Why |
|-------|--------|-----|
| [e.g., Framework] | [Choice] | [Reason, or **(research needed)**] |

### Architecture
A one-page, plain-English view of the system: the building blocks and how they connect.

> [How the pieces fit together]

**Building blocks:** (include only what this project needs)
- **Frontend:** [What the user sees and does]
- **Backend:** [Business logic and API approach]
- **Database:** [What the app needs to remember]
- **Auth:** [How users sign in, if accounts are needed]
- **File storage:** [User uploads or generated files, if any]

**How the blocks connect:**
```
User → Frontend → Backend API → Database
                      ↘ [External service] ([purpose])
```

### Data Model
_Main entities, their key fields, and how they relate. Not a full schema._

- [Entity: key fields, relationships]

### External Services and Setup
_Third-party APIs, AI models, payments, email, and anything the user must create or configure before building: accounts, API keys, domains, environments._

- [Service or setup step + purpose + who does it]

### Research Needed
- [Uncertain choice + what to find out — e.g., "Auth: Supabase Auth vs. Clerk"]

---

## 3. Verification: Success and Proof
_Define the proof before implementation. These are planned checks, not claims that verification has already passed. Keep criteria specific to this project's scope; omit checks that don't apply._

### Successful Outcome
[What can the user accomplish when this work is complete? Describe the observable result.]

### Verification Criteria and Methods
_Each required outcome needs a suitable check and a clear passing result. Include important failure cases as well as the happy path. If the spec spans multiple milestones, identify which milestone each criterion belongs to._

| Criterion | How to verify | Passing result |
|-----------|---------------|----------------|
| [Required behavior or outcome] | [Test, walkthrough, measurement, or review, including relevant inputs] | [Specific observable evidence or threshold] |
| [Important failure or edge case] | [How to exercise the condition] | [Expected handling and observable result] |

### End-to-End Proof
_Describe the main user journey to exercise from start to finish, through the real user path as a user would, not internal shortcuts or test-only endpoints. Check the actual outcome, not just whether individual components pass tests._

- **Environment:** [Local / staging / production, as appropriate to the requested scope]
- **How it's driven:** [Browser, terminal, HTTP calls, or another way an agent exercises the real app]
- **Starting state and inputs:** [Required setup and representative data]
- **Steps:** [User actions from start to finish, through the real user path — no test-only shortcuts]
- **Expected final result:** [What must be observable when the journey completes]
- **Evidence to capture:** [Relevant test output, screenshot, measurement, or review result, plus side effects such as saved records, files written, or messages sent]

### Verification Constraints
_Note checks that need user review, unavailable credentials, external access, or a longer observation period. If blocked, report the specific criterion that remains unverified; a substitute check does not establish the original outcome._

- [Constraint, affected criterion, and what is needed to complete verification — or "None"]

---

## Assumptions and Open Questions
- **Assumption:** [Belief the plan relies on, and what changes if it's wrong]
- **Open question:** [Decision to make before building, and who makes it]

## What Agents Should Ask You
_When an agent builds from this spec, what should it check with you about?_

- **Check with me first:** [e.g., new paid services, changes to existing data, anything public-facing]

Show the project spec template

Project Spec: [Name]

Source: [brainstorm doc, issue, or request] Date: [YYYY-MM-DD] Deadline: [Date and why, if there is one]

Overview

Type: [internal tool / personal project / public product / MVP / learning project]

[1-2 sentences: what it is, who it’s for, and why it’s being built]

1. Product Requirements

Who it’s for and the job to be done

Target user: [Specific user description]
Job to be done: When [situation], they want to [motivation], so they can [outcome].

Problems it solves

[Problem]

Key user flows

[Flow, step by step at a high level]

UI/UX

Screens or surfaces, look and feel (with reference apps), and accessibility or usability needs.

[Screen, interaction, or design reference]

Scope and milestones

MVP (Milestone 1): the minimum needed to validate the idea.

[Feature]

Deferred (not in the MVP, may come later):

[Item planned for V2 or later]

Out of scope (not part of this project):

[Explicit exclusion]

V2 (Milestone 2):

[Feature]

Future versions:

[Idea for later]

2. Engineering Requirements

Record the decisions that are expensive to reverse or need the user: stack, architecture, data model, outside services and setup, and anything the user wants to review before code exists. Leave implementation detail, such as full schemas and API endpoints, to build time.

Tech Stack

Layer	Choice	Why
[e.g., Framework]	[Choice]	[Reason, or (research needed)]

Architecture

A one-page, plain-English view of the system: the building blocks and how they connect.

[How the pieces fit together]

Building blocks: (include only what this project needs)

Frontend: [What the user sees and does]
Backend: [Business logic and API approach]
Database: [What the app needs to remember]
Auth: [How users sign in, if accounts are needed]
File storage: [User uploads or generated files, if any]

How the blocks connect:

User → Frontend → Backend API → Database
                      ↘ [External service] ([purpose])

Data Model

Main entities, their key fields, and how they relate. Not a full schema.

[Entity: key fields, relationships]

External Services and Setup

Third-party APIs, AI models, payments, email, and anything the user must create or configure before building: accounts, API keys, domains, environments.

[Service or setup step + purpose + who does it]

Research Needed

[Uncertain choice + what to find out — e.g., “Auth: Supabase Auth vs. Clerk”]

3. Verification: Success and Proof

Define the proof before implementation. These are planned checks, not claims that verification has already passed. Keep criteria specific to this project’s scope; omit checks that don’t apply.

Successful Outcome

[What can the user accomplish when this work is complete? Describe the observable result.]

Verification Criteria and Methods

Each required outcome needs a suitable check and a clear passing result. Include important failure cases as well as the happy path. If the spec spans multiple milestones, identify which milestone each criterion belongs to.

Criterion	How to verify	Passing result
[Required behavior or outcome]	[Test, walkthrough, measurement, or review, including relevant inputs]	[Specific observable evidence or threshold]
[Important failure or edge case]	[How to exercise the condition]	[Expected handling and observable result]

End-to-End Proof

Describe the main user journey to exercise from start to finish, through the real user path as a user would, not internal shortcuts or test-only endpoints. Check the actual outcome, not just whether individual components pass tests.

Environment: [Local / staging / production, as appropriate to the requested scope]
How it’s driven: [Browser, terminal, HTTP calls, or another way an agent exercises the real app]
Starting state and inputs: [Required setup and representative data]
Steps: [User actions from start to finish, through the real user path — no test-only shortcuts]
Expected final result: [What must be observable when the journey completes]
Evidence to capture: [Relevant test output, screenshot, measurement, or review result, plus side effects such as saved records, files written, or messages sent]

Verification Constraints

Note checks that need user review, unavailable credentials, external access, or a longer observation period. If blocked, report the specific criterion that remains unverified; a substitute check does not establish the original outcome.

[Constraint, affected criterion, and what is needed to complete verification — or “None”]

Assumptions and Open Questions

Assumption: [Belief the plan relies on, and what changes if it’s wrong]
Open question: [Decision to make before building, and who makes it]

What Agents Should Ask You

When an agent builds from this spec, what should it check with you about?

Check with me first: [e.g., new paid services, changes to existing data, anything public-facing]

Feature spec template

create-spec/references/feature_spec_template.md

Select and copy the complete source below.

# Feature Spec: [Feature Name]

**Source:** [brainstorm doc, issue, or request]
**Date:** [YYYY-MM-DD]
**Deadline:** [Date and why, if there is one]

## Overview
> [1-2 sentences: what the feature does and why it's needed]

---

## 1. Product Requirements

### Who it's for and the job to be done
- **User:** [Who uses this feature]
- **Job to be done:** When [situation], they want to [motivation], so they can [outcome].

### Requirements
- [Functional requirement]

### UI/UX
_Screens or surfaces affected, interactions, and design references. Omit if the feature has no interface._

- [Screen, interaction, or design reference]

### Edge Cases
| Scenario | Expected Behavior |
|----------|-------------------|
| [Edge case] | [How to handle] |

### Out of Scope
- [Explicit exclusion for this feature]

---

## 2. Engineering Requirements
_Record the decisions that are expensive to reverse or need the user: data, API, and dependency changes, outside services and setup, and anything the user wants to review before code exists. Leave implementation detail to build time._

### Scope of Changes
_The areas of the app this touches (e.g., checkout flow, billing API, admin dashboard), not a list of files. Label what's confirmed in the code separately from what's inferred._

- [Area + what changes]

### Data, API, and Dependency Changes
_New or changed tables, fields, endpoints, or libraries, if any._

- [Change]

### External Services and Setup
_New third-party services, accounts, keys, or configuration the user must provide, if any._

- [Service or setup step + who does it]

---

## 3. Verification: Success and Proof
_Define the proof before implementation. These are planned checks, not claims that verification has already passed. Keep criteria specific to this feature's scope; omit checks that don't apply._

### Successful Outcome
[What can the user accomplish when this work is complete? Describe the observable result.]

### Verification Criteria and Methods
_Each required outcome needs a suitable check and a clear passing result. Include important failure cases as well as the happy path. Reference the Edge Cases section where relevant so expected behavior and verification stay aligned. Include rows for specific existing behavior this change could break, especially anything that shares code with it and lacks a test; not a general "nothing else breaks."_

| Criterion | How to verify | Passing result |
|-----------|---------------|----------------|
| [Required behavior or outcome] | [Test, walkthrough, measurement, or review, including relevant inputs] | [Specific observable evidence or threshold] |
| [Important failure or edge case] | [How to exercise the condition] | [Expected handling and observable result] |
| [Specific existing behavior this change could break] | [Regression check] | [Still behaves as before] |

### End-to-End Proof
_Describe the main user journey to exercise from start to finish, through the real user path as a user would, not internal shortcuts or test-only endpoints. Check the actual outcome, not just whether individual components pass tests._

- **Environment:** [Local / staging / production, as appropriate to the requested scope]
- **How it's driven:** [Browser, terminal, HTTP calls, or another way an agent exercises the real app]
- **Starting state and inputs:** [Required setup and representative data]
- **Steps:** [User actions from start to finish, through the real user path — no test-only shortcuts]
- **Expected final result:** [What must be observable when the journey completes]
- **Evidence to capture:** [Relevant test output, screenshot, measurement, or review result, plus side effects such as saved records, files written, or messages sent]

### Verification Constraints
_Note checks that need user review, unavailable credentials, external access, or a longer observation period. If blocked, report the specific criterion that remains unverified; a substitute check does not establish the original outcome._

- [Constraint, affected criterion, and what is needed to complete verification — or "None"]

---

## Assumptions and Open Questions
- **Assumption:** [Belief the plan relies on, and what changes if it's wrong]
- **Open question:** [Decision to make before building, and who makes it]

## What Agents Should Ask You
_When an agent builds from this spec, what should it check with you about?_

- **Check with me first:** [e.g., new paid services, changes to existing data, anything public-facing]

Show the feature spec template

Feature Spec: [Feature Name]

Source: [brainstorm doc, issue, or request] Date: [YYYY-MM-DD] Deadline: [Date and why, if there is one]

Overview

[1-2 sentences: what the feature does and why it’s needed]

1. Product Requirements

Who it’s for and the job to be done

User: [Who uses this feature]
Job to be done: When [situation], they want to [motivation], so they can [outcome].

Requirements

[Functional requirement]

UI/UX

Screens or surfaces affected, interactions, and design references. Omit if the feature has no interface.

[Screen, interaction, or design reference]

Edge Cases

Scenario	Expected Behavior
[Edge case]	[How to handle]

Out of Scope

[Explicit exclusion for this feature]

2. Engineering Requirements

Record the decisions that are expensive to reverse or need the user: data, API, and dependency changes, outside services and setup, and anything the user wants to review before code exists. Leave implementation detail to build time.

Scope of Changes

The areas of the app this touches (e.g., checkout flow, billing API, admin dashboard), not a list of files. Label what’s confirmed in the code separately from what’s inferred.

[Area + what changes]

Data, API, and Dependency Changes

New or changed tables, fields, endpoints, or libraries, if any.

[Change]

External Services and Setup

New third-party services, accounts, keys, or configuration the user must provide, if any.

[Service or setup step + who does it]

3. Verification: Success and Proof

Define the proof before implementation. These are planned checks, not claims that verification has already passed. Keep criteria specific to this feature’s scope; omit checks that don’t apply.

Successful Outcome

[What can the user accomplish when this work is complete? Describe the observable result.]

Verification Criteria and Methods

Each required outcome needs a suitable check and a clear passing result. Include important failure cases as well as the happy path. Reference the Edge Cases section where relevant so expected behavior and verification stay aligned. Include rows for specific existing behavior this change could break, especially anything that shares code with it and lacks a test; not a general “nothing else breaks.”

Criterion	How to verify	Passing result
[Required behavior or outcome]	[Test, walkthrough, measurement, or review, including relevant inputs]	[Specific observable evidence or threshold]
[Important failure or edge case]	[How to exercise the condition]	[Expected handling and observable result]
[Specific existing behavior this change could break]	[Regression check]	[Still behaves as before]

End-to-End Proof

Environment: [Local / staging / production, as appropriate to the requested scope]
How it’s driven: [Browser, terminal, HTTP calls, or another way an agent exercises the real app]
Starting state and inputs: [Required setup and representative data]
Steps: [User actions from start to finish, through the real user path — no test-only shortcuts]
Expected final result: [What must be observable when the journey completes]
Evidence to capture: [Relevant test output, screenshot, measurement, or review result, plus side effects such as saved records, files written, or messages sent]

Verification Constraints

[Constraint, affected criterion, and what is needed to complete verification — or “None”]

Assumptions and Open Questions

Assumption: [Belief the plan relies on, and what changes if it’s wrong]
Open question: [Decision to make before building, and who makes it]

What Agents Should Ask You

When an agent builds from this spec, what should it check with you about?

Check with me first: [e.g., new paid services, changes to existing data, anything public-facing]

When to use it

How it works

1 Explore first

2 Ask only the rest

3 Pick the spec

4 Fill in the template

5 Save it

6 Finish

What you get

For a big project

For a feature

Next step

Install /create-spec

Full instructions & templates

Create Spec

Gather context

Ask only what matters

Write the spec

Finish

Project Spec: [Name]

Overview

1. Product Requirements

Who it’s for and the job to be done

Problems it solves

Key user flows

UI/UX

Scope and milestones

2. Engineering Requirements

Tech Stack

Architecture

Data Model

External Services and Setup

Research Needed

3. Verification: Success and Proof

Successful Outcome

Verification Criteria and Methods

End-to-End Proof

Verification Constraints

Assumptions and Open Questions

What Agents Should Ask You

Feature Spec: [Feature Name]

Overview

1. Product Requirements

Who it’s for and the job to be done

Requirements

UI/UX

Edge Cases

Out of Scope

2. Engineering Requirements

Scope of Changes

Data, API, and Dependency Changes

External Services and Setup

3. Verification: Success and Proof

Successful Outcome

Verification Criteria and Methods

End-to-End Proof

Verification Constraints

Assumptions and Open Questions

What Agents Should Ask You