# 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. - Skill: `kw12121212/spec-driven-auto` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add kw12121212/spec-driven-auto` - Raw SKILL.md: https://api.skillmd.com/api/skills/kw12121212/spec-driven-auto/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Productivity - Author: kw12121212 (https://skillmd.com/u/kw12121212) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/kw12121212/spec-driven-auto --- You are running the full spec-driven workflow end-to-end for a single change. ## 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. ```yaml propose: node {{SKILL_DIR}}/scripts/spec-driven.js propose apply: node {{SKILL_DIR}}/scripts/spec-driven.js apply verify: node {{SKILL_DIR}}/scripts/spec-driven.js verify audit-unmapped-spec-evidence: node {{SKILL_DIR}}/scripts/spec-driven.js audit-unmapped-spec-evidence [--implementation ...] [--tests ...] verify-spec-mappings: node {{SKILL_DIR}}/scripts/spec-driven.js verify-spec-mappings archive: node {{SKILL_DIR}}/scripts/spec-driven.js archive ``` ## 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 1. **Load context** — rebuild working context from the current files before doing anything: - You MUST treat all prior conversational context as stale, unreliable, and non-authoritative. - You MUST NOT use prior chat context as a source of truth for requirements, task state, implementation details, or completion status. - You MUST rebuild working context from the current change artifacts, relevant base specs, and the current repository state before taking any workflow action. - If prior chat context differs from the files or repository state in any way, you MUST discard the prior chat context and follow the files and repository state only. - Do not use prior chat context unless it has been explicitly re-validated against the current files and repository state. 2. **Assess complexity** — before doing anything else, evaluate the change using a two-tier model: - Read `.spec-driven/config.yaml` for project context - Read `.spec-driven/specs/INDEX.md` and 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 - **Classify the change into one of two tiers:** - **Green** (proceed): clear scope and a concrete definition of done within a single repository, including changes that touch up to 15 modules or packages, modify up to 50 files, involve schema migrations with data transformation, modify existing auth/authz/payment logic, or make cross-cutting changes across multiple subsystems — proceed automatically - **Red** (suggest brainstorm): requires coordinating across multiple services or repositories, scope is vague or open-ended (e.g. "refactor the codebase", "improve performance"), or has no clear definition of done — explain why and suggest running `/spec-driven-brainstorm` first to converge the idea, then entering `/spec-driven-auto` to execute the resulting proposal - If Red, stop and suggest brainstorm - If Green, proceed 3. **Propose** — run `/spec-driven-propose`: - Run `node {{SKILL_DIR}}/scripts/spec-driven.js propose ` - Fill all artifacts: proposal.md (with Unchanged Behavior), specs/ delta files, design.md, tasks.md (with ## Testing), questions.md (open questions) - Show the user a summary: scope, key decisions, task count, unchanged behaviors, and any open questions - If questions.md has open questions, list them and **stop for user resolution** before proceeding — do not continue until every open question is explicitly resolved - If there are no open questions, proceed directly to Step 4 without waiting for confirmation 4. **Apply** — implement all tasks: - Run `node {{SKILL_DIR}}/scripts/spec-driven.js apply ` to show task summary - Check questions.md for open `- [ ] Q:` entries — if any, present each unresolved question using: - `Question` - `Explanation` - `Impact` - `Recommendation` - `Explanation` must clarify why the question is still unresolved after reading the current change artifacts, relevant main specs, and repository state - `Impact` must describe what implementation choice, task, behavior, or unchanged-behavior guarantee depends on the answer - `Recommendation` may suggest a preferred answer, but only as a suggestion - After presenting those blocks, ask the user to answer or confirm the decision needed, and stop until the user explicitly resolves every open question - You MAY recommend a preferred answer, but only as a suggestion; you MUST NOT treat your own recommendation as a resolved answer or continue implementation until the user explicitly confirms it - Work through each `- [ ]` task in order: read code, implement, verify Unchanged Behavior, mark `- [x]` - For `## Testing` tasks: actually run the tests and confirm they pass - Run `node {{SKILL_DIR}}/scripts/spec-driven.js apply ` to confirm `remaining === 0` 5. **Verify** — check completeness: - Run `node {{SKILL_DIR}}/scripts/spec-driven.js verify ` - Then perform the rest of the `/spec-driven-verify` checks: task completion, open questions, implementation evidence, and spec alignment - If the change-local evidence set includes implementation files or directly verifying test files, run `node {{SKILL_DIR}}/scripts/spec-driven.js audit-unmapped-spec-evidence [--implementation ...] [--tests ...]` as part of this verify pass and treat its current-change blocking findings the same way `/spec-driven-verify` would - Treat script `errors` plus any CRITICAL findings from those checks as blockers - If there are blockers you can safely fix, fix them automatically, then rerun both `node {{SKILL_DIR}}/scripts/spec-driven.js verify ` and the verification pass - If any blocker cannot be auto-fixed: stop and ask the user - Re-read delta spec files and update them to match what was actually implemented - Ensure delta spec mapping frontmatter reflects the implementation and test files actually changed or relied on 6. **Review** — check code quality: - Read every file changed by this change - Review findings must be author-agnostic: do not trust or excuse code just because it was generated or edited earlier in this same auto run - Check: readability, security, error handling, performance, best practices, test quality - Reuse the verify-phase `node {{SKILL_DIR}}/scripts/spec-driven.js audit-unmapped-spec-evidence [--implementation ...] [--tests ...]` result unless review fixes changed the relevant implementation or direct test files; only rerun that same command when the reviewed evidence set materially changed - MUST FIX issues: fix them automatically, then re-review - If MUST FIX issues cannot be auto-fixed: stop and ask the user - SHOULD FIX and NITS: fix if straightforward, otherwise note in the final report 7. **Archive** — close out the change: - Confirm there are no incomplete tasks before archiving - List all delta files in `specs/` and merge each into the corresponding main spec file - If `changes//specs/` is empty, proceed without confirmation — changes without spec impact are valid - Update `.spec-driven/specs/INDEX.md` if new spec files were created - Run `node {{SKILL_DIR}}/scripts/spec-driven.js verify-spec-mappings` after merging mapping frontmatter into main specs - Run `node {{SKILL_DIR}}/scripts/spec-driven.js archive ` - If `.spec-driven/roadmap/` exists, treat any milestone declared status or roadmap index updates performed by the archive command as part of archive closeout - Report the final result: what was built, files changed, tests passing, archive location, and any roadmap status changes caused by archive - If the user wants to commit and push the completed archived change, offer `/spec-driven-ship ` as the next explicit handoff. Keep that handoff advisory only: do not stage files, inspect push eligibility, enter that workflow, commit, or push unless the user explicitly chooses it. ## Rules - The context reset in Step 1 is mandatory — never skip it - The complexity check in Step 2 is mandatory — never skip it - The workflow runs fully automatically — do not pause for confirmation except when open questions in questions.md need user resolution - Additional confirmations are required whenever the workflow is blocked by unresolved questions - All other steps run automatically unless blocked by an unresolvable issue - Follow all config.yaml rules (specs, change, code, test) throughout - If anything goes wrong mid-flow, stop and explain — do not silently continue - Mark tasks complete one at a time, not in bulk - Recommended answers do not count as question resolution without explicit user confirmation - Keep implementation and test mappings in frontmatter, not in requirement prose - Do not commit or push automatically. Shipping is handled only by the explicit `/spec-driven-ship ` workflow after successful archive closeout.