Skip to content

Spec-driven development

The SpecDrivenDevelopment module installs spec-kit-ears-tdd v0.1.0 from its immutable GitHub release wheel. The resource verifies SHA-256 before installing the tool in an isolated uv tool environment. The wheel pins the published specify-cli==0.16.3 release; neither dependency is installed from a Git branch or checkout.

No elevation or UAC is required.

The state resource and generated ears-sdd.ps1 launcher are compatible with both PowerShell 7 and inbox Windows PowerShell 5.1. Spec Kit's selected project-script variant is Python, independent of the calling PowerShell runtime; the generated project also carries PowerShell helper scripts.

Test and install the tool

Use the focused human command first:

pwsh -NoProfile -File .\scripts\Set-SpecDrivenDevelopmentState.ps1 -Mode Test
pwsh -NoProfile -File .\scripts\Set-SpecDrivenDevelopmentState.ps1 -Mode Ensure
powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\scripts\Set-SpecDrivenDevelopmentState.ps1 -Mode Test

The module form includes the managed uv package dependency automatically:

.\Apply-Workstation.ps1 -Mode Test -Module SpecDrivenDevelopment -Plan
.\Apply-Workstation.ps1 -Mode Ensure -Module SpecDrivenDevelopment

Use -SkipSpecDrivenDevelopment only with the legacy full run. Do not combine skip switches with explicit -Module selection.

Adopt the policy in a project

Tool installation does not modify a project. Adoption writes Spec Kit commands, templates, workflow metadata, launchers, and a project-local policy file. Run it from the target project and review the resulting diff:

ears-sdd init --project . --integration codex
git diff -- .agents .specify ears-sdd ears-sdd.ps1

The source remains in its standalone repository. A consuming project receives only the installed Spec Kit artifacts and project-specific configuration.

Edit .specify/ears-sdd.toml for the project's production roots, test roots, and real test command. Then use the human validator:

.\ears-sdd.ps1 validate --phase spec
.\ears-sdd.ps1 validate --phase plan
.\ears-sdd.ps1 validate --phase tasks
.\ears-sdd.ps1 validate --phase final
.\ears-sdd.ps1 status --phase final

The same launcher works from inbox Windows PowerShell:

powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\ears-sdd.ps1 status --phase final

For agent consumption, add --json. The installed Codex command is $speckit-ears-validate-validate, and the gated workflow is ears-sdd.

Enforced boundary

  • Specifications use stable REQ-NNN identifiers and one EARS shall obligation per requirement.
  • Every requirement maps to automated tests or a justified manual verification.
  • Tests may name requirement IDs; production code may not contain IDs or copied requirement prose.
  • Validation is read-only and does not silently execute the project's configured test command.

The final gate verifies that a real test command is declared. Run that command separately so test execution remains visible and attributable.

Feature governance before publication

New workstation modules and capability routes that expose state commands must reference their dedicated feature directory. Run the observational human command directly:

pwsh -NoProfile -File .\scripts\Test-SpecFeatureGovernance.ps1
pwsh -NoProfile -File .\scripts\Test-SpecFeatureGovernance.ps1 -Json | ConvertFrom-Json

The guard verifies that each non-grandfathered declaration names a normalized child of specs/, that spec.md, plan.md, tasks.md, and traceability.toml exist, and that the referenced feature passes ears-sdd validate --feature <directory> --phase final. It never changes the active feature selection and ignores unrelated drafts until a catalog entry references them.

Historical modules and state routes are listed explicitly in config/spec-feature-governance.psd1. Their deterministic fingerprint makes any exception-boundary change visible in both human and JSON output. The pre-commit hook invokes this same command; it does not use an automation-only policy path.