Feature Team
Spawn a 3-agent team (Backend Dev + Frontend Dev + QA) to implement features from PRDs. Agents own separate file territories and coordinate via messaging.
How It Works
- PRD / feature request: A spec or task description to implement
- Define the Definition of Done: The contract: requirements + quality gate + E2E checks
- Map file territories: Backend / Frontend / QA — no overlaps
- Spawn 3 agents
- Monitor & resolve blockers: Forward each request to the responsible agent
- Integration check: Build + full test suite + smoke test
- Open PR: Feature merged-ready with tests passing
Invocation Triggers
/feature-teambuild featureimplement PRDfull-stack featureUse Cases
- Implement a full-stack feature from a PRD or task description
- Build a new page with backend API + frontend UI in parallel
- Add a feature with automated QA gate before merge
The Problem
Building a feature solo means constantly switching between backend logic, frontend state, and test coverage. By the time you finish the API, you have forgotten what you planned for the UI. The QA is always an afterthought, which means it always finds problems you have to go back and fix. Feature Team runs all three in parallel — coordinated, gated, and accountable to a DOD you write before a single line of code.
What It Does
- 1Define the Definition of Done
Non-negotiable before spawning agents. Functional requirements, quality gate (>= 3 tests per module, no lint errors, build passes), and E2E verification steps. This is the contract all three agents work against.
- 2Map file territories
Backend owns API routes, models, services. Frontend owns pages, components, hooks. QA owns test files only. No overlaps. If a file would belong to two agents, pick one owner — the other sends a message describing what they need.
- 3Spawn all 3 agents in parallel
Backend Dev, Frontend Dev, and QA Engineer are dispatched simultaneously. Frontend can mock backend endpoints while waiting for the real API; QA starts writing tests against the DOD immediately.
- 4Monitor and resolve blockers
Agents communicate via messaging. Common blockers: frontend waiting for a type definition, QA finding a DOD failure, merge conflict risk on shared config. Each blocker is resolved by forwarding the specific request to the responsible agent.
- 5Integration check and PR
After all 3 report done: run build from root, run full test suite, quick manual smoke test. If anything fails, re-dispatch the responsible agent with the specific error. Then create the PR.
What You Get / What It Doesn't Do
- Full-stack feature implemented with passing tests, front and back
- DOD checklist verified by the QA agent — pass/fail per item
- PR created with summary of what was built and what was tested
- No merge conflicts — territory ownership was defined upfront
- Make product decisions — it executes against the DOD you define
- Resolve architectural review comments without your input
- Handle features that span more than one repository
- Replace the integration check — you still verify before merging
Tips
Merge conflicts are painful to untangle mid-build. Ten minutes mapping file ownership saves an hour of conflict resolution.
Write it before any code, not after. Agents that finish without a DOD to grade against report "done" based on their own judgment — which is not good enough.
Frontend can mock, but types must be agreed upfront. If backend is not ready, frontend mocks with the correct shape and notes the dependency explicitly.
Get the Skill
Unlock the full Feature Team SKILL.md — drop it into ~/.claude/skills/ and trigger it by name.
- Full-stack feature implemented with passing tests, front and back
- DOD checklist verified by the QA agent — pass/fail per item
- PR created with summary of what was built and what was tested
- No merge conflicts — territory ownership was defined upfront
Commonly Used With
29 more production skills ready to install.