Menu
Use when building new modules or features where teammates can each own a separate piece without stepping on each other
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Use when facing a task that could benefit from parallel work - decides whether to use subagents or agent teams, then composes the right team from the role pool based on task analysis
Use when debugging with unclear root cause and multiple plausible explanations that need parallel adversarial testing to converge on the answer
Use when changes span frontend, backend, and tests where each layer needs a dedicated owner plus an integration agent for cross-cutting consistency
Use when multiple aspects of a problem need parallel investigation with findings shared and challenged between investigators
Use at the end of every team session or work session to record mistakes, lessons, and patterns to .claude.md for self-evolution across sessions
| name | feature-development |
| description | Use when building new modules or features where teammates can each own a separate piece without stepping on each other |
Each teammate owns an independent module or component. They build in parallel without interfering. An integrator ensures cross-module consistency.
Core principle: Conway's Law as a tool — structure the team to mirror the desired architecture.
Management theory: Conway's Law (team structure → system architecture), T-Shaped Skills (specialists who understand the whole), Belbin role coverage.
Don't use when:
coordinator (lead, delegate mode recommended)
├── architect × 1 (designs interfaces, reviews contracts)
├── implementer × 2-3 (one per module)
├── reviewer × 1 (code quality + spec compliance)
└── integrator × 1 (optional: cross-module consistency)
Belbin coverage:
Sizing by feature scope:
| Feature Size | Team | Notes |
|---|---|---|
| 2 modules | 3-4 | coordinator + 2 implementers + reviewer |
| 3-4 modules | 4-5 | + architect for interface design |
| 5+ modules | 5-7 | + integrator, or split into sub-teams |
Before spawning implementers:
Critical: Interface contracts MUST be locked before implementation starts (Tuckman's Norming). Changing contracts mid-build invalidates parallel work.
Contract template:
Module A provides:
- function doX(input: TypeA): TypeB
- emits event "x-complete" with payload TypeC
Module B consumes:
- calls A.doX() with [specific inputs]
- listens for "x-complete"
Agreed data types: [shared types file]
Each implementer:
File ownership rule: No two implementers touch the same file. If shared code is needed, the integrator or architect handles it.
Coordinator in delegate mode:
Integrator (or coordinator):
Structure your team to produce the architecture you want:
| Desired Architecture | Team Structure |
|---|---|
| Microservices | 1 implementer per service |
| Monolith with modules | 1 implementer per module, shared integrator |
| Frontend + Backend | 1 FE impl + 1 BE impl (see cross-layer pattern) |
| Plugin system | 1 impl for core + 1 per plugin |
Anti-pattern: Splitting by file instead of by feature. This produces files that "work" in isolation but features that don't cohere.
| Mistake | Fix |
|---|---|
| Start implementing before contracts locked | Norming gate: plan must be approved |
| Two implementers editing same file | Assign file ownership explicitly |
| No integration phase | Integrator role exists for this |
| Coordinator starts coding | Enable delegate mode |
| Contracts too vague | Include data types + error cases |
| No shared types file | Architect creates it before implementation |
Pre-requisite: team-orchestrator:orchestrating-work routes here Post-requisite: team-orchestrator:session-reflection records learnings Related: superpowers:subagent-driven-development for single-session alternative