| name | feature |
| description | Start next feature — full workflow from issue triage through spec-driven development to shipping. |
| argument-hint | Optionally specify an issue number or feature description |
| compatibility | Requires spec-kit project structure with .specify/ directory |
| metadata | {"author":"jabelk","source":"claude-code-template"} |
| user-invocable | true |
Start Next Feature
Full workflow from issue triage to implementation. Do NOT skip steps.
Phase 1: Orient (always do this first)
- Read
CLAUDE.md and .specify/memory/constitution.md to refresh context
- Read
MEMORY.md for project status, user preferences, and active work
- Run
gh issue list --state open --limit 30 to see the current backlog
- Run
git log --oneline -10 to see recent work
- Present a summary: "Here's where we are, here's what's open, here's what I'd recommend next"
- Wait for user input on which issue(s) to tackle
Phase 2: Research (do NOT skip this)
Before specifying or planning, research online:
- Are there better approaches than the obvious one?
- What do competitors/similar projects do?
- Any libraries, APIs, or patterns that would save time?
- Check if the approach has known pitfalls
Present findings to user. This step has repeatedly prevented bad architectural decisions.
Phase 3: Specify
- Run
/speckit-specify with the feature description
- This creates the branch and spec automatically
- Review for plot holes, missing edge cases, unclear requirements
- Wait for user feedback before proceeding
Phase 4: Plan + Tasks
- Run
/speckit-plan — research decisions, data model, architecture
- Run
/speckit-tasks — task breakdown with dependencies
- If anything needs clarification, run
/speckit-clarify
- If quality check needed, run
/speckit-analyze
Phase 4.5: Review (do NOT skip this)
- Run
/review-plan — sends spec + plan to OpenAI gpt-5.3-codex and Gemini 2.5 Pro for independent peer review
- The script outputs raw text from each model — you must read the output and interpret the GREEN/YELLOW/RED ratings manually
- Present all three reviews to the user with a summary
- If any RED: strongly recommend fixes; proceed only with explicit user approval
- If any YELLOW: review with user and decide whether to fix first
- If all providers are SKIPPED (missing API keys): flag to user, perform manual architectural review as fallback
- Wait for user approval before moving to Phase 5
Phase 5: Implement
- Run
/speckit-implement — execute tasks phase by phase
- TDD where appropriate: write failing test first, then fix, then verify
- VERIFY BEFORE SHIPPING: For any new library integration, read the actual installed source code and run a minimal working example BEFORE writing the full implementation
- Clean up tests, docs, and code as you go — don't leave debt
- Verify file-by-file after any bulk operations
- Run lint and test commands after each phase
Phase 6: Ship
- Self-review the diff for: shell pipeline safety (
pipefail), API keys in URLs, secrets/PII in external calls, doc consistency
- Run tests — all must pass
git diff --stat — review, no unintended changes
- Create PR against main
- Address any CI/review findings before merging
- Merge when approved
- Verify deployment