spec-driven-auto
You are running the full spec-driven workflow end-to-end for a single change.
Prerequisites
The .spec-driven/ directory must exist at the project root. Before proceeding, verify:
ls .spec-driven/
If this fails, the project is not initialized. Run /spec-driven-init first.
Steps
- Assess complexity — before doing anything, evaluate whether this change is suitable for the auto workflow:
- Read
.spec-driven/config.yamlfor project context - Read
.spec-driven/specs/INDEX.mdand relevant spec files to understand the current system - Read the codebase files that the change will likely touch — estimate the number of files, modules, and cross-cutting concerns involved
- Reject if any of these are true:
- The change touches more than 3 modules or packages
- The change requires modifying more than ~10 files
- Read
More from kw12121212/slim-spec-driven
spec-driven-init
Initialize a .spec-driven/ directory in a project. Creates config.yaml, roadmap/, and specs/ scaffold, then guides the user to fill in project context.
15spec-driven-archive
Archive a completed spec-driven change. Requires completed tasks, merges delta specs into main specs, then moves the change to archive/ with a date prefix.
15spec-driven-propose
Propose a new spec-driven change. Scaffolds proposal.md, specs/ delta files, design.md, tasks.md, and questions.md for a named change, populated with project context.
15spec-driven-verify
Verify a spec-driven change is complete and correctly implemented. Checks task completion, implementation evidence, and spec alignment.
14spec-driven-review
Review the code quality of a spec-driven change. Checks readability, security, performance, and best practices before archiving.
14spec-driven-apply
Implement the tasks in a spec-driven change. Works through incomplete tasks one by one, marking each complete as it goes.
14