| name | implementation |
| description | Implement the next pending feature from feature-list.json. Lean loop: pick feature, implement with tests, verify all checks pass, commit, mark done. Use when features are pending and you're ready to build. Also use when user says 'build next feature', 'implement', 'start coding', 'what's next', or after /init-project has created the feature list. |
| model | sonnet |
| effort | medium |
| allowed-tools | Read, Write, Edit, Bash, Glob, Grep |
Implementation
Pick the next feature. Build it. Verify it. Ship it.
Gotchas
| Gotcha | What happens | Do instead |
|---|
| Committing before verify passes | Broken code lands in history, needs revert or fixup | Always run verify.sh first — commit only on exit 0 |
| Reading full feature-list.json | Burns context tokens as feature list grows (33+ features) | Use feature.py next to get just the one feature you need |
| Script fails, agent rewrites it | Loses project-specific customizations from /init-project | Read the script, fix the broken command — never recreate |
| Forgetting to update CLAUDE.md | Architecture/Key Files drift from actual codebase | Check if you added/removed modules — update if so |
Workflow
1. Pick Feature
python .claude/scripts/feature.py next
Returns the highest-priority pending feature whose dependencies are resolved. If no features ready, stop and tell the user.
2. Implement
- Read the project CLAUDE.md for architecture, key files, and conventions
- Read existing code before modifying — understand the patterns in use
- Write the implementation following project conventions
- Write tests — happy path + at least one error path
The goal is working code with tests, not perfect code. Ship, then iterate.
3. Verify
bash .claude/scripts/verify.sh
Runs lint → test → build in order, stops at first failure. Fix the issue, rerun from top. Only proceed to commit when exit code is 0.
If verify.sh is missing or stale, run the checks from CLAUDE.md Commands table manually.
4. Commit
Stage only the files you changed. Commit with the feature ID:
feat(FT-XXX): short description of what was built
5. Update & Mark Done
- If you added/removed modules, models, or key files → update CLAUDE.md (Architecture, Key Files, Commands)
- If the feature revealed new verification needs → update
.claude/scripts/verify.sh
- Mark done:
python .claude/scripts/feature.py done FT-XXX
Scripts Reference
Scripts live in .claude/scripts/. Created by /init-project, tailored per project.
| Script | What it does | When to update |
|---|
feature.py | Feature CRUD: next, get, done, add, list, summary. Reads/writes .claude/progress/feature-list.json. | Never — project-agnostic |
verify.sh | Runs lint → test → build in order, set -e stops at first failure. Exit 0 = all pass. | When a feature adds a new check (e.g., type check, new linter, integration test command) |
dev-server.sh | Installs deps + starts dev server. | When dependencies change, entry point moves, or a new service is added |
If a script fails: read it, fix the broken command, do NOT delete and rewrite. The structure (set -e, echo headers, command order) is intentional and project-specific.
Rules
- Never commit with failing checks — broken commits create revert churn that wastes more time than the fix
- Never skip tests for production code — untested code is unverified code, and the agent can't self-correct without tests
- Read files before editing — modifying code you haven't read produces wrong assumptions and wasted iterations
- One feature per cycle — context switching mid-feature leads to half-finished work in both
- Never recreate scripts from scratch — they contain project-specific customizations from /init-project that you can't rederive
