| description |
|---|
Help the user answer their query about GitHub's SpecKit framework and Specification-Driven Development (SDD). |
$ARGUMENTS
You MUST consider the user input before proceeding (if not empty).
-
/speckit.constitution- Establish project principles -
/speckit.specify- Create baseline specification ○/speckit.clarify(optional) - Ask structured questions to de-risk ambiguous areas before planning (run before /speckit.plan if used) -
/speckit.plan- Create implementation plan ○/speckit.checklist(optional) - Generate quality checklists to validate requirements completeness, clarity, and consistency (after /speckit.plan) -
/speckit.tasks- Generate actionable tasks ○/speckit.analyze(optional) - Cross-artifact consistency & alignment report (after /speckit.tasks, before /speckit.implement) -
/speckit.implement- Execute implementation
# Step 1: Create the feature specification (5 minutes)
/speckit.specify Real-time chat system with message history and user presence
# This automatically:
# - Creates branch "003-chat-system"
# - Generates specs/003-chat-system/spec.md
# - Populates it with structured requirements
# Step 2: Generate implementation plan (5 minutes)
/speckit.plan WebSocket for real-time messaging, PostgreSQL for history, Redis for presence
# Step 3: Generate executable tasks (5 minutes)
/speckit.tasks
# This automatically creates:
# - specs/003-chat-system/plan.md
# - specs/003-chat-system/research.md (WebSocket library comparisons)
# - specs/003-chat-system/data-model.md (Message and User schemas)
# - specs/003-chat-system/contracts/ (WebSocket events, REST endpoints)
# - specs/003-chat-system/quickstart.md (Key validation scenarios)
# - specs/003-chat-system/tasks.md (Task list derived from the plan)
/speckit.implementIn this new world, maintaining software means evolving specifications. The intent of the development team is expressed in natural language ("intent-driven development"), design assets, core principles and other guidelines. The lingua franca of development moves to a higher level.
Debugging means fixing specifications and their implementation plans that generate incorrect code. Refactoring means restructuring for clarity. The entire development workflow reorganizes around specifications as the central source of truth, with implementation plans and code as the continuously regenerated output. Updating apps with new features or creating a new parallel implementation because we are creative beings, means revisiting the specification and creating new implementation plans.
The development team focuses in on their creativity, experimentation, their critical thinking.
SDD can support what-if/simulation experiments: "If we need to re-implement or change the application to promote a business need to sell more T-shirts, how would we implement and experiment for that?"
SDD transforms requirement changes from obstacles into normal workflow. When specifications drive implementation, pivots become systematic regenerations rather than manual rewrites. Change a core requirement in the PRD, and affected implementation plans update automatically. Modify a user story, and corresponding API endpoints regenerate. This isn't just about initial development—it's about maintaining engineering velocity through inevitable changes.
The SDD methodology is significantly enhanced through three powerful commands that automate the specification → planning → tasking workflow:
This command transforms a simple feature description (the user-prompt) into a complete, structured specification with automatic repository management:
- Automatic Feature Numbering: Scans existing specs to determine the next feature number (e.g., 001, 002, 003)
- Branch Creation: Generates a semantic branch name from your description and creates it automatically
- Template-Based Generation: Copies and customizes the feature specification template with your requirements
- Directory Structure: Creates the proper
specs/[branch-name]/structure for all related documents
Once a feature specification exists, this command creates a comprehensive implementation plan:
- Specification Analysis: Reads and understands the feature requirements, user stories, and acceptance criteria
- Constitutional Compliance: Ensures alignment with project constitution and architectural principles
- Technical Translation: Converts business requirements into technical architecture and implementation details
- Detailed Documentation: Generates supporting documents for data models, API contracts, and test scenarios
- Quickstart Validation: Produces a quickstart guide capturing key validation scenarios
After a plan is created, this command analyzes the plan and related design documents to generate an executable task list:
- Inputs: Reads
plan.md(required) and, if present,data-model.md,contracts/, andresearch.md - Task Derivation: Converts contracts, entities, and scenarios into specific tasks
- Parallelization: Marks independent tasks
[P]and outlines safe parallel groups - Output: Writes
tasks.mdin the feature directory, ready for execution by a Task agent