// Use when the user provides a complete spec, requirements document, or feature description and wants fully autonomous end-to-end implementation without interactive brainstorming - chains specify, plan, tasks, analyze, implement, then lint/security/finish
| name | spec-kit-auto |
| description | Use when the user provides a complete spec, requirements document, or feature description and wants fully autonomous end-to-end implementation without interactive brainstorming - chains specify, plan, tasks, analyze, implement, then lint/security/finish |
Autonomous end-to-end orchestrator that chains spec-kit commands. Takes complete input, runs the full pipeline, with no human interaction between phases.
Core principle: The user's input is the spec. Enrich it, plan it, build it, verify it. Only stop for blocking ambiguity.
This is a rigid skill. Follow it exactly.
Commit after each phase completes.
Specify -> Plan -> Tasks -> Analyze -> Implement -> Lint & Security -> Finish
Applies to all phases. Resolve by: (1) checking project docs — CLAUDE.md, memory, architecture files, existing patterns; (2) following existing codebase conventions; (3) choosing the simpler option (YAGNI); (4) documenting the decision in the spec or plan.
Only escalate to the user when two valid interpretations would produce fundamentally different architectures, the decision requires domain knowledge absent from all available documents, or getting it wrong would require a full rewrite.
Invoke the Skill tool with skill: "speckit.specify" and pass the user's input as args.
Wait for it to complete. Commit the resulting spec.
Invoke the Skill tool with skill: "speckit.plan".
Wait for it to complete. Commit the resulting plan and design artifacts.
Invoke the Skill tool with skill: "speckit.tasks".
Wait for it to complete. Commit the resulting tasks.md.
Invoke the Skill tool with skill: "speckit.analyze".
This is a quality gate. If CRITICAL issues are found, fix them before proceeding. Re-run analyze after fixes until no CRITICAL issues remain.
Invoke the Skill tool with skill: "speckit.implement".
Wait for it to complete. All tasks in tasks.md should be marked [X].
Run linting, security scanning, and code review. Three parallel tracks:
Detect project linters from config files and run them:
| Config File | Linter | Command |
|---|---|---|
pyproject.toml / ruff.toml | ruff | ruff check --fix . |
pyproject.toml [tool.black] | black | black . |
.eslintrc* / eslint.config.* | eslint | npx eslint --fix . |
Cargo.toml | clippy + rustfmt | cargo clippy && cargo fmt |
.golangci.yml | golangci-lint | golangci-lint run |
Makefile | checkmake | checkmake Makefile |
Dockerfile* | hadolint | hadolint Dockerfile |
.github/workflows/*.yml | actionlint | actionlint |
*.sh | shellcheck | shellcheck *.sh |
docs/**/*.md | markdownlint | markdownlint docs/**/*.md --fix |
Run all detected linters. Fix auto-fixable issues. Report unfixable issues.
Run the CodeRabbit CLI for code review aligned with team standards.
Auth check: Before running, verify authentication:
command -v coderabbit >/dev/null 2>&1 || { echo "coderabbit CLI not installed, skipping Track B"; }
coderabbit auth status 2>&1 | grep -q "Logged in" || { echo "Not authenticated. Run: coderabbit auth login"; }
If not authenticated or not installed, skip this track and note it in the final report.
Fix all actionable findings. Skip false positives with a note.
Dispatch a subagent to review all changed files (git diff main...HEAD). Also reference the project's security-standards.md context file if one exists. Review for:
For each finding: file, line(s), severity (critical/high/medium), specific risk, fix. Fix all critical and high findings. Document medium findings for review.
Check if a lint workflow using wearerequired/lint-action@v2 exists in .github/workflows/. If missing, create .github/workflows/lint.yml with checkout, language-appropriate linter installation (use uv pip install for Python), and auto_fix: false. Adapt to match detected project languages. Check for existing lint workflows first to avoid duplication.
git diff main...HEAD --stat to summarize all changes.| Excuse | Reality |
|---|---|
| "Input is unclear, need to ask" | Enrich from project context. Only ask if blocking. |
| "Security review is overkill for this change" | Every change gets reviewed. No exceptions. |
| "Linter not installed, skip it" | Note it in the report. Don't silently skip. |
| "Tests pass, skip verification" | Verification means running them NOW and showing output. |
| "CodeRabbit isn't authenticated" | Skip with a note. Run the other two tracks. |
| "This is too simple for the full pipeline" | Simple changes are where skipped steps cause the most damage. |
| "I'll reorder phases for efficiency" | Follow the pipeline exactly. No reordering. |
| "Analyze found nothing critical, skip fixes" | Good. Move to the next phase. |
| "Design contradicts CLAUDE.md but seems better" | CLAUDE.md wins. Always. |
Spec-kit commands invoked (in order):
| Phase | Slash command | Purpose |
|---|---|---|
| 1 | /speckit.specify | Create feature specification |
| 2 | /speckit.plan | Create implementation plan |
| 3 | /speckit.tasks | Generate actionable task list |
| 4 | /speckit.analyze | Cross-artifact consistency check |
| 5 | /speckit.implement | Execute all tasks |
| 6 | (inline) | Lint, CodeRabbit, security review |
| 7 | (inline) | Test, summarize, integrate |