* docs(scripts): document the 'py' script type and sh/ps migration plan (#3284) Bring remaining docs up to date with the Python (`py`) workflow-script variant introduced in #3277, and record the retention/deprecation plan for the shell variants. - AGENTS.md: document the `scripts:` frontmatter (sh/ps/py), clarify the `{SCRIPT}` placeholder resolution, and add a "Script Types and Migration" section (why py is recommended, defaults, phased sh/ps deprecation path). Note the Python agent-context variant. - docs/quickstart.md, docs/local-development.md: mention the `py` variant and `--script sh|ps|py`. - docs/reference/integrations.md: add `py` to the `--script` rows for install/switch/upgrade. - .devcontainer/devcontainer.json: auto-approve `.specify/scripts/python/`. Closes #3284. Assisted-by: GitHub Copilot (model: Claude Opus 4.8, autonomous) Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 298d6ec2-a330-49bc-9394-fe2b77f25ff3 * docs(scripts): address review — accurate paths, prompt behavior, scoped py claims Addresses the review on PR #3653: - AGENTS.md: fix the agent-context Python path to its real `extensions/agent-context/scripts/python/` location. - AGENTS.md: qualify that only templates that invoke a helper script carry `scripts:` frontmatter (constitution/specify do not). - AGENTS.md: narrow the availability claim — `py` covers the core command templates; the bundled extensions ship Python scripts on disk but their command templates still invoke shell variants, so `--script py` does not yet route extension commands to Python. - AGENTS.md / quickstart / local-development: describe the interactive prompt vs. non-interactive OS default instead of "auto-selects". - local-development: add `--script py` to the wrong-script-type fix. Assisted-by: GitHub Copilot (model: Claude Opus 4.8, autonomous) Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 298d6ec2-a330-49bc-9394-fe2b77f25ff3 * docs(scripts): trim deprecation timeline, correct parity/scope claims (review) Addresses the second review on PR #3653: - Remove the speculative four-phase deprecation timeline from AGENTS.md. A forward-looking removal schedule is roadmap content, not contributor guidance, and its phases lacked an actionable adoption signal. Replace it with the concrete contributor parity rule plus a one-line current-posture note pointing removal work to the #3277 epic. - Stop stating dual-maintenance as already eliminated: reframe "single source of truth" as the intended direction, noting all three variants are still maintained in parallel today. - Correct the parity-coverage claim: Python ports have output-parity tests where the contract is stdout-based and unit tests elsewhere, rather than every file being compared to every shell counterpart. - Scope the `scripts:` frontmatter rule to core command templates and note the agent-context/git extension templates don't use it yet. Assisted-by: GitHub Copilot (model: Claude Opus 4.8, autonomous) Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 298d6ec2-a330-49bc-9394-fe2b77f25ff3 --------- Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
6.2 KiB
Quick Start Guide
This guide will help you get started with Spec-Driven Development using Spec Kit. Throughout, we illustrate each step with a running example: Taskify, a small team productivity platform.
Note
Automation scripts are provided as Bash (
.sh), PowerShell (.ps1), and Python (.py) variants. Interactivespecify initprompts you to choose one; non-interactive runs default to a shell variant for your OS. Pass--script sh|ps|pyto select explicitly.
Note
Commands are shown here in
/speckit.*form, but the exact invocation depends on your agent. Some skills-based agents use$speckit-*(e.g. Codex, ZCode) or/skill:speckit-*(e.g. Kimi). Use whichever form your agent exposes — the steps are otherwise identical.
Recommended Process
Tip
Context Awareness: Spec Kit tracks the active feature by the feature directory recorded in
.specify/feature.json(overridable with theSPECIFY_FEATURE_DIRECTORYenvironment variable). Commands resolve the feature from that state, not from the checked-out Git branch — no Git required. The opt-in git extension adds numbered feature branches (e.g.001-feature-name) for organizing work in version control, but the active feature is still whichever directory that state points to;git checkoutalone does not change it. To point commands at a different feature, update.specify/feature.json(or setSPECIFY_FEATURE_DIRECTORY).
After installing Spec Kit, each command below is a step in the process. Two paths are common:
Shorter path — for smaller features:
/speckit.specify/speckit.plan/speckit.tasks/speckit.implement/speckit.converge
Full path — for production features, adding /speckit.clarify, /speckit.checklist, and /speckit.analyze as quality gates:
/speckit.constitution/speckit.specify/speckit.clarify/speckit.plan/speckit.checklist/speckit.tasks/speckit.analyze/speckit.implement/speckit.converge
Install Specify
In your terminal, install the CLI from PyPI (requires uv), then initialize your project:
uv tool install specify-cli
specify init taskify # or: specify init . to use the current directory
init lets you pick your coding agent interactively, or pass it explicitly with --integration (e.g. --integration copilot).
Note
Prefer
pipx, one-timeuvxruns, a pinned release, or an offline/air-gapped setup? See the Installation Guide for all supported methods.
Step 1: /speckit.constitution — set the ground rules
Establishes the project's guiding principles, which every later step is evaluated against. Run it once up front, passing your principles as arguments.
/speckit.constitution Taskify is a "Security-First" application. All user inputs must be validated. We use a microservices architecture. Code must be fully documented.
Step 2: /speckit.specify — describe what to build
Creates the feature specification from a natural-language description. Focus on the what and why, not the tech stack.
/speckit.specify Develop Taskify, a team productivity platform where predefined users create projects, assign tasks, comment, and move tasks across Kanban columns (To Do, In Progress, In Review, Done). Five users (one product manager, four engineers), three sample projects, no login for this first phase.
Step 3: /speckit.clarify — resolve ambiguities
Asks targeted questions about anything underspecified and folds your answers back into the spec, so you're not planning on top of ambiguity. Run it before planning, optionally with a focus area.
/speckit.clarify Focus on task card behavior — status changes, comment permissions, and user assignment.
Step 4: /speckit.plan — choose the tech stack
Generates the design artifacts from the spec. This is where implementation detail belongs — provide your tech stack and architecture.
/speckit.plan Use .NET Aspire with Postgres. The frontend is Blazor Server with drag-and-drop boards and real-time updates. Expose REST APIs for projects, tasks, and notifications.
Step 5: /speckit.checklist — validate the spec
Generates a quality checklist — "unit tests for your requirements" — to confirm the spec is complete, clear, and consistent before you break the work down.
/speckit.checklist
Step 6: /speckit.tasks — break the work down
Generates an actionable, dependency-ordered tasks.md from the design artifacts.
/speckit.tasks
Step 7: /speckit.analyze — check consistency
Reports conflicts, gaps, and ambiguities across spec.md, plan.md, and tasks.md. It's read-only — if it flags issues, fix them at the source and re-run before implementing.
/speckit.analyze
Step 8: /speckit.implement — build it
Executes the tasks in tasks.md in dependency order. Run it once to build everything, or scope it to one phase at a time for large features.
/speckit.implement
Step 9: /speckit.converge — verify completeness
Checks the codebase against the spec, plan, and tasks. If it finds gaps, it appends new tasks to tasks.md; run /speckit.implement and converge again until it reports converged. Otherwise you're done — proceed to review or open a PR.
/speckit.converge
Tip
For a full reference on each command — arguments, output, phased implementation, and how they interact — see Agentic SDD.
Key Principles
- Be explicit about what you're building and why
- Don't focus on tech stack during specification phase
- Iterate and refine your specifications before implementation
- Validate requirements and plans before coding begins
- Let the coding agent handle the implementation details
Next Steps
- See the Agentic SDD reference for full detail on every command
- Read the complete methodology for in-depth guidance
- Check out more examples in the repository
- Explore the source code on GitHub