3.3 KiB
description, scripts
| description | scripts | ||||
|---|---|---|---|---|---|
| Create or update the feature specification from a natural language feature description. |
|
The user input to you can be provided directly by the agent or as a command argument - you MUST consider it before proceeding with the prompt (if not empty).
User input:
$ARGUMENTS
The text the user typed after /specify in the triggering message is the feature description. Assume you always have it available in this conversation even if {ARGS} appears literally below. Do not ask the user to repeat it unless they provided an empty command.
Given that feature description, do this:
-
Run the script
{SCRIPT}from repo root and parse its JSON output for BRANCH_NAME and SPEC_FILE. All file paths must be absolute. IMPORTANT You must only ever run this script once. The JSON is provided in the terminal as output - always refer to it to get the actual content you're looking for. -
Load
templates/spec-template.mdto understand required sections. -
Follow this execution flow:
- Parse user description from Input If empty: ERROR "No feature description provided"
- Extract key concepts from description Identify: actors, actions, data, constraints
- For each unclear aspect: Mark with [NEEDS CLARIFICATION: specific question]
- Fill User Scenarios & Testing section If no clear user flow: ERROR "Cannot determine user scenarios"
- Generate Functional Requirements Each requirement must be testable Mark ambiguous requirements
- Identify Key Entities (if data involved)
- Return: SUCCESS (spec ready for planning)
-
Write the specification to SPEC_FILE using the template structure, replacing placeholders with concrete details derived from the feature description (arguments) while preserving section order and headings.
-
Report completion with branch name, spec file path, and readiness for the next phase.
NOTE: The script creates and checks out the new branch and initializes the spec file before writing.
General Guidelines
Quick Guidelines
- Focus on WHAT users need and WHY.
- Avoid HOW to implement (no tech stack, APIs, code structure).
- Written for business stakeholders, not developers.
- DO NOT create any checklists that are embedded in the spec. That will be a separate command.
Section Requirements
- Mandatory sections: Must be completed for every feature
- Optional sections: Include only when relevant to the feature
- When a section doesn't apply, remove it entirely (don't leave as "N/A")
For AI Generation
When creating this spec from a user prompt:
- Mark all ambiguities: Use [NEEDS CLARIFICATION: specific question] for any assumption you'd need to make
- Don't guess: If the prompt doesn't specify something (e.g., "login system" without auth method), mark it
- Think like a tester: Every vague requirement should fail the "testable and unambiguous" checklist item
- Common underspecified areas:
- User types and permissions
- Data retention/deletion policies
- Performance targets and scale
- Error handling behaviors
- Integration requirements
- Security/compliance needs