spec-driven-maintenance
You are helping the user manage the manual maintenance workflow.
This Skill's Commands
If you cannot remember the exact command used by this skill, look it up here before running anything. Do not guess.
run-maintenance: node {{SKILL_DIR}}/scripts/spec-driven.js run-maintenance [path]
Prerequisites
The target project must already contain .spec-driven/ at the project root.
Before proceeding, verify:
ls .spec-driven/
If this fails, run /spec-driven-init first.
Steps
-
Choose the maintenance action:
- Run the maintenance workflow manually right now
- Inspect or adjust the maintenance config
-
Read existing maintenance assets when present:
.spec-driven/maintenance/config.json- Relevant README or project docs that define lint/test/typecheck commands
-
For a manual maintenance run — run:
node {{SKILL_DIR}}/scripts/spec-driven.js run-maintenance [path]Then report whether the run:
- failed because the maintenance config is missing or invalid
- skipped because the repo was dirty, had no configured checks, or already had an active maintenance change
- completed cleanly because all configured checks already passed
- found unfixable failures
- became blocked during fix, archive, commit, or branch-restore work
- created a maintenance branch/change and repaired the configured checks
-
When editing config:
- Keep
checkslimited to commands the repo explicitly supports - Only add
fixCommandfor deterministic, low-risk repairs - Use
changePrefix,branchPrefix, andcommitMessagePrefixonly when the repo needs custom naming
- Keep
Rules
- Do not add speculative
fixCommandentries for semantically ambiguous test failures - Treat the maintenance config as the source of truth for allowed maintenance fixes
- If a maintenance run leaves a blocked change behind, report that clearly instead of pretending the repair succeeded
More from kw12121212/auto-spec-driven
spec-driven-auto
Run the full spec-driven workflow automatically. Proposes, implements, verifies, reviews, and archives a change without mandatory confirmation — only stops for user input when open questions need resolution.
36spec-driven-review
Review the code quality of a spec-driven change. Checks readability, security, performance, and best practices before archiving.
36spec-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.
35spec-driven-verify
Verify a spec-driven change is complete and correctly implemented. Checks task completion, implementation evidence, and spec alignment.
35spec-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.
35spec-driven-brainstorm
Discuss and brainstorm a spec-driven change from a rough idea, then propose a change name and, after explicit confirmation, generate the same five proposal artifacts as spec-driven-propose.
35