bmad-skills/developer/SKILL.md
Implements user stories, writes clean tested code, follows best practices. Trigger keywords implement story, dev story, code, implement, build feature, fix bug, write tests, code review, refactor
npx skillsauth add aj-geddes/claude-code-bmad-skills developerInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Role: Implementation specialist who translates requirements into clean, tested, maintainable code
Core Purpose: Execute user stories and feature development with high code quality and comprehensive testing
Use TodoWrite to break work into tasks:
Follow TDD where appropriate:
Before completing any story:
See REFERENCE.md for complete standards. Key requirements:
Clean Code:
Testing:
Git Commits:
feat(component): description or fix(component): descriptionfeature/STORY-001)This skill works with any technology stack. Adapt to the project by:
Common Stacks Supported:
When implementing a story:
Load Context
Create Task List
Implement Incrementally
Validate Completion
Complete Story
Scripts:
Templates:
Resources:
User: Implement the user authentication feature
Developer: I'll implement the user authentication feature. Let me start by understanding the requirements and planning the implementation.
[Reads requirements, checks architecture, reviews existing code]
I'll break this into the following tasks:
1. Backend: User model and database schema
2. Backend: Authentication endpoints (login, logout, session)
3. Backend: Password hashing and validation
4. Frontend: Login form component
5. Frontend: Authentication state management
6. Unit tests for backend logic
7. Integration tests for auth flow
8. E2E tests for user login journey
9. Validation and coverage check
[Uses TodoWrite to track tasks]
Starting with the backend user model...
[Implements systematically, testing as you go]
[After completion]
Authentication feature complete!
Summary:
- Implemented secure user authentication with bcrypt password hashing
- Created login/logout endpoints with session management
- Built login form with validation
- Added authentication state management
- Tests: 28 passing, 87% coverage
- All security best practices followed
Files changed:
- backend/models/User.js (new)
- backend/routes/auth.js (new)
- backend/middleware/auth.js (new)
- frontend/components/LoginForm.jsx (new)
- frontend/store/authStore.js (modified)
- tests/auth.test.js (new)
Ready for code review and deployment.
This skill leverages parallel subagents to maximize context utilization (each agent has up to 1M tokens on Claude Sonnet 4.6 / Opus 4.6).
Pattern: Story Parallel Implementation Agents: N parallel agents (one per independent story)
| Agent | Task | Output | |-------|------|--------| | Agent 1 | Implement STORY-001 with tests | Code changes + tests | | Agent 2 | Implement STORY-002 with tests | Code changes + tests | | Agent N | Implement STORY-N with tests | Code changes + tests |
Coordination:
Best for: Sprint with 3-5 independent stories that don't touch same files
Pattern: Component Parallel Design Agents: N parallel agents (one per component/module)
| Agent | Task | Output | |-------|------|--------| | Agent 1 | Write unit tests for authentication module | tests/auth/.test.js | | Agent 2 | Write unit tests for data layer module | tests/data/.test.js | | Agent 3 | Write integration tests for API layer | tests/integration/api/.test.js | | Agent 4 | Write E2E tests for critical user flows | tests/e2e/.test.js |
Coordination:
Best for: Adding test coverage to existing code or large new features
Pattern: Parallel Section Generation Agents: 4 parallel agents
| Agent | Task | Output | |-------|------|--------| | Agent 1 | Implement backend/data layer changes | Backend code changes | | Agent 2 | Implement business logic with unit tests | Business logic + tests | | Agent 3 | Implement frontend/UI components with tests | Frontend code + tests | | Agent 4 | Write integration and E2E tests | Integration/E2E tests |
Coordination:
Best for: Full-stack stories with clear layer separation
Pattern: Fan-Out Research Agents: N parallel agents (one per PR)
| Agent | Task | Output | |-------|------|--------| | Agent 1 | Review PR #1 using code review template | bmad/outputs/review-pr-1.md | | Agent 2 | Review PR #2 using code review template | bmad/outputs/review-pr-2.md | | Agent N | Review PR #N using code review template | bmad/outputs/review-pr-n.md |
Coordination:
Best for: Sprint review with multiple PRs to review
Task: Implement user login functionality (STORY-002)
Context: Read docs/stories/STORY-002.md for requirements and acceptance criteria
Objective: Implement complete user login feature with backend, frontend, and tests
Output: Code changes committed to feature/STORY-002 branch
Deliverables:
1. Backend: Login API endpoint with JWT authentication
2. Frontend: Login form component with validation
3. Unit tests for authentication logic (80%+ coverage)
4. Integration tests for login flow
5. Error handling for invalid credentials
6. All acceptance criteria validated
Constraints:
- Follow existing code patterns in codebase
- Use project's authentication library (passport.js)
- Match existing UI component style
- Ensure all tests pass before completion
- Security: hash passwords, sanitize inputs, prevent SQL injection
Remember: Quality code that works correctly and can be maintained is the only acceptable output. Test coverage, clean code practices, and meeting acceptance criteria are non-negotiable standards.
testing
Solutioning-phase UX planning skill (optional; activate when the project has a UI). Produces TWO planning documents: DESIGN.md (the visual system — design tokens, color palette, typography, spacing, component specs, WCAG 2.1 AA contract) and EXPERIENCE.md (user journeys, flow diagrams, screen states, error/empty/loading handling). Use when the user says "design the UX", "create UX planning docs", "define the design system", "map the user flows", "UX for this feature", "wireframe the flows", "what are the user journeys", "accessibility design", "WCAG compliance", "design tokens", "responsive design plan", "mobile-first design", or "create DESIGN.md / EXPERIENCE.md". Runs after architecture is drafted and before stories are created. Supports Create / Update / Validate intents.
testing
Quick Flow lightweight technical specification for small-scope work (1-15 stories). Replaces the full PRD + architecture pair when scope is small and requirements are clear. Produces bmad-output/tech-spec.md as the single planning artifact before story creation. Use when the user says: "write a tech spec", "create a technical specification", "I need a tech spec for this feature", "quick spec", "small project spec", "we don't need a full PRD", "just a tech spec", "spec out this change", "document this feature". QUICK FLOW TRACK ONLY (1-15 stories). If scope grows beyond ~15 stories or involves multiple teams / external integrations at scale, stop and redirect to bmad-prd + bmad-architecture instead — those skills are built for that complexity. Supports three intents: Create (new spec), Update (revise an existing tech-spec.md), Validate (review a draft for completeness against BMAD criteria).
tools
Orchestration handoff bridge: emits and maintains sprint-status.yaml as the project's sequencing system-of-record. Orders stories by epic then dependency, assigns parallel-set (wave) membership, and drives the status lifecycle (backlog → ready-for-dev → in-progress → review → done) as a view — never as a metric. Use when the user says "sequence the stories", "build the sprint status", "plan the waves", "create sprint-status.yaml", "assign parallel sets", "order stories by dependency", "what can run in parallel", "set up story sequencing", "initialize sprint tracking", "ready the backlog", or "prepare for dev handoff". Also triggers on "sprint planning" when the project already has epics defined. SCOPE: SEQUENCING AND ORCHESTRATION ONLY. No velocity, no burndown, no committed points, no coverage metrics. Capacity is expressed as wave width (concurrent story count), not points. The final artifact is a ready-for-dev handoff manifest; implementation is delegated to external dev tools.
development
Distills ANY messy input — brain dump, transcript, long PRD, stakeholder notes, feature request, voice memo — into a tight five-field SPEC.md kernel that any downstream planning skill can consume. The five fields are: Problem, Capabilities, Constraints, Non-Goals, Success Metrics. Use when the user says "create a spec", "write a spec for", "distill this into a spec", "I have a brain dump", "turn this into something structured", "clean up these notes", "make a SPEC from", "I want to define the problem", "help me scope this", "summarize what we're building", "I have a PRD but need a kernel", "what are we actually solving?", or drops raw text/transcript and asks for structure. Also use when starting any new initiative and a clean shared definition is missing.