Spec Kit: from testable intent to traceable acceptance
Install and update Spec Kit without confusing toolkit setup with application deployment
Choose a pinned installation, the right script variant and explicit integration, then protect existing project files during initialization and upgrades.
What you will learn
- Install a development toolkit, not a production server
- Initialize an empty project with explicit choices
- Treat upgrades and delivery as separate operations
Before you start
- Basic requirements, Git and testing concepts
- Understanding of local development versus application deployment
Trace a small feature from intent to evidence and distinguish workflow contracts from verified behavior.
Key takeaways
- The toolkit installation is distinct from application deployment.
- Choose script type and integration explicitly for a learning project.
- A version check does not establish package provenance.
Install a development toolkit, not a production server
The pinned installation guide requires Python 3.11 or later and describes source and PyPI distribution for specify-cli. It recommends uv for package management and also supports pipx. Windows has PowerShell scripts without requiring WSL; Bash, PowerShell and Python script variants are available.
Select a release deliberately and record its source instead of copying an old example version as the latest recommendation. The source commit used for this article identifies our evidence, not a promise that it is the best release to install. We did not install or upgrade tools in this workspace.
Initialize an empty project with explicit choices
The example below assumes Specify is already installed and creates a new practice directory using the PowerShell script variant. Replace the integration only after checking what your installed version supports. Avoid force-initializing the current non-empty repository while learning; first inspect which instruction and template files initialization will add.
The README documents --non-interactive for unattended sessions and --ignore-agent-tools for obtaining templates without checking agent tooling. The latter does not install or authenticate the missing agent. A successful specify version reports availability and version, not proof of the executable’s distribution origin.
Treat upgrades and delivery as separate operations
The README distinguishes specify self check from self upgrade --dry-run and the actual self upgrade command. The bare upgrade executes rather than merely presenting a plan. Preserve local overrides and inspect compatibility before updating a team’s workflow; record the old installation and project state for recovery.
Spec Kit does not make your generated application live merely by initializing its artifacts. Application build, tests, configuration, deployment and post-deployment acceptance belong to the target project. No cloud resource, repository hook, package installation or live release was created for this tutorial.
Decision guide
| Criterion | Option A | Option B |
|---|---|---|
| Best when | You need predictable behavior and easy auditing | You need adaptive optimization and have reliable telemetry |
| Main risk | May leave performance on the table | Can become difficult to explain or debug |
Implementation steps
- 1
Record a chosen release and supported runtime.
- 2
Initialize a new disposable directory.
- 3
Inspect generated files and agent availability.
- 4
Preview upgrades before changing the installation.
Copy-ready example
specify version
specify init speckit-practice --integration copilot --script ps --non-interactive
specify self check
specify self upgrade --dry-runFrequently asked questions
Is WSL mandatory on Windows?
The inspected installation guide supports PowerShell scripts directly on Windows.
Does --ignore-agent-tools install the agent?
No. It skips the tooling check; it does not provide or authenticate the agent.
Sources
- Spec Kit / docs/installation.mdSource checked 2026-09-14
- Spec Kit / README.mdSource checked 2026-09-14