mirror of
https://github.com/github/spec-kit.git
synced 2026-01-31 13:03:36 +00:00
71 lines
3.3 KiB
Markdown
71 lines
3.3 KiB
Markdown
---
|
|
description: Create or update the feature specification from a natural language feature description.
|
|
scripts:
|
|
sh: scripts/bash/create-new-feature.sh --json "{ARGS}"
|
|
ps: scripts/powershell/create-new-feature.ps1 -Json "{ARGS}"
|
|
---
|
|
|
|
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:
|
|
|
|
1. 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.
|
|
2. Load `templates/spec-template.md` to understand required sections.
|
|
|
|
3. Follow this execution flow:
|
|
|
|
1. Parse user description from Input
|
|
If empty: ERROR "No feature description provided"
|
|
2. Extract key concepts from description
|
|
Identify: actors, actions, data, constraints
|
|
3. For each unclear aspect:
|
|
Mark with [NEEDS CLARIFICATION: specific question]
|
|
4. Fill User Scenarios & Testing section
|
|
If no clear user flow: ERROR "Cannot determine user scenarios"
|
|
5. Generate Functional Requirements
|
|
Each requirement must be testable
|
|
Mark ambiguous requirements
|
|
6. Identify Key Entities (if data involved)
|
|
7. Return: SUCCESS (spec ready for planning)
|
|
|
|
4. 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.
|
|
5. 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:
|
|
|
|
1. **Mark all ambiguities**: Use [NEEDS CLARIFICATION: specific question] for any assumption you'd need to make
|
|
2. **Don't guess**: If the prompt doesn't specify something (e.g., "login system" without auth method), mark it
|
|
3. **Think like a tester**: Every vague requirement should fail the "testable and unambiguous" checklist item
|
|
4. **Common underspecified areas**:
|
|
- User types and permissions
|
|
- Data retention/deletion policies
|
|
- Performance targets and scale
|
|
- Error handling behaviors
|
|
- Integration requirements
|
|
- Security/compliance needs |