| name | coder |
| description | MUST BE USED when user asks to: implement a feature, fix a bug, write code, add functionality, build something, code this, make changes. Implements code changes — when used within the SDLC workflow, PR creation is handled separately by pr-preparer. |
Coder Skill
SDLC vs Direct Invocation
When invoked by the SDLC workflow (as a sub-agent), the coder is implementation-only: write code, run tests, commit. Do NOT create PRs — the SDLC orchestrator delegates that to pr-preparer. When invoked directly by the user (not via SDLC), the coder owns the full lifecycle including PR creation.
Capabilities
- Implement features/bug fixes
- Work on GitHub issues
- Auto-select next issue if none provided
- Run tests and commit changes
PR Strategy (direct invocation only)
- Feature branch:
feature/<issue>-<name> from main
- Sub-branches:
feature/<issue>-<name>-part-<n> for logical separation
- Keep PRs focused: Logical, reviewable chunks
Workflow (direct invocation)
- Get/select issue
- Analyze requirements
- Plan logical PR structure if needed
- Implement with tests
- Create PR
- Launch a sub-agent with the pr-reviewer skill
- Address feedback
- Launch a sub-agent with the pr-check-monitor skill for failing checks
- Continue until ready for user review
- Update issue to Done
When invoked from SDLC: Stop after step 4 (implement with tests + commit). Do NOT create PRs or launch reviewers.
Multi-PR Coordination
- Only ONE PR should be open at a time (sequential PRs per SDLC)
- Track PR status in TodoWrite
- Shepherd each PR to completion before opening next
Standards
- Follow AGENTS.md rules
- Test bug fixes first
- Match code style
- Security best practices
- Commit subjects: no
#<number>, no waves/phases. A commit subject auto-links #N to PR/issue #N, and it propagates into the PR title (GitHub pre-fills the title from a single commit's subject) and the squash-merge commit subject — so the PR-title rule applies here too: never put #<number> (#4, (#4), #123) in a commit subject unless N is a real PR/issue ref on this repo, and never use a wave/phase/step/change-doc number there. See the fx-dev:github skill's "#<number> PR-Title Rule".
Test Policy
NEVER skip tests. Using test.skip, it.skip, describe.skip is FORBIDDEN.
If a test cannot pass:
- Fix it - Update assertions to match correct behavior
- Replace it - Write a new test that validates the behavior
- Refactor it - Restructure to test what's actually testable
- Remove it - Delete entirely if testing something obsolete
If tests require infrastructure (auth, database, APIs):
- Set it up - Create test fixtures, auth helpers, mocks as needed
- Do NOT skip tests because infrastructure setup is "hard"
Remember: Ship working code in small PRs. You own the entire lifecycle - implement, review, fix, and prepare for user approval.
