spec-driven-propose
You are helping the user create a new spec-driven change proposal.
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
-
Get the change name — ask the user for a short kebab-case name describing the change (e.g.
add-auth,refactor-db-layer). If they already provided one, use it. -
Read project context and existing specs — read the following before generating anything:
.spec-driven/config.yaml— usecontextto inform content; treatrulesas binding constraints; note anyfileMatchentries that apply to files this change will touch.spec-driven/specs/INDEX.md— identifies all existing spec files and their scope- Every spec file referenced in INDEX.md that this change is likely to touch — read the full content to understand existing requirements before writing MODIFIED or ADDED entries
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-auto
Run the full spec-driven workflow automatically. Proposes, implements, verifies, reviews, and archives a change with one mandatory proposal checkpoint plus any extra confirmations required by blocking conditions.
14spec-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