Parallel Feature Development

1---2name: parallel-feature-development3description: Coordinate parallel feature development with file ownership strategies, conflict avoidance rules, and integration patterns for multi-agent implementation. Use this skill when decomposing a large feature into independent work streams, when two or more agents need to implement different layers of the same system simultaneously, when establishing file ownership to prevent merge conflicts in a shared codebase, when designing interface contracts so parallel implementers can build against each other's APIs before they are ready, or when deciding whether to use vertical slices versus horizontal layers for a full-stack feature.4version: 1.0.25---6 7# Parallel Feature Development8 9Strategies for decomposing features into parallel work streams, establishing file ownership boundaries, avoiding conflicts, and integrating results from multiple implementer agents.10 11## When to Use This Skill12 13- Decomposing a feature for parallel implementation14- Establishing file ownership boundaries between agents15- Designing interface contracts between parallel work streams16- Choosing integration strategies (vertical slice vs horizontal layer)17- Managing branch and merge workflows for parallel development18 19## File Ownership Strategies20 21### By Directory22 23Assign each implementer ownership of specific directories:24 25```26implementer-1: src/components/auth/27implementer-2: src/api/auth/28implementer-3: tests/auth/29```30 31**Best for**: Well-organized codebases with clear directory boundaries.32 33### By Module34 35Assign ownership of logical modules (which may span directories):36 37```38implementer-1: Authentication module (login, register, logout)39implementer-2: Authorization module (roles, permissions, guards)40```41 42**Best for**: Feature-oriented architectures, domain-driven design.43 44### By Layer45 46Assign ownership of architectural layers:47 48```49implementer-1: UI layer (components, styles, layouts)50implementer-2: Business logic layer (services, validators)51implementer-3: Data layer (models, repositories, migrations)52```53 54**Best for**: Traditional MVC/layered architectures.55 56## Conflict Avoidance Rules57 58### The Cardinal Rule59 60**One owner per file.** No file should be assigned to multiple implementers.61 62### When Files Must Be Shared63 64If a file genuinely needs changes from multiple implementers:65 661. **Designate a single owner** — One implementer owns the file672. **Other implementers request changes** — Message the owner with specific change requests683. **Owner applies changes sequentially** — Prevents merge conflicts694. **Alternative: Extract interfaces** — Create a separate interface file that the non-owner can import without modifying70 71### Interface Contracts72 73When implementers need to coordinate at boundaries:74 75```typescript76// src/types/auth-contract.ts (owned by team-lead, read-only for implementers)77export interface AuthResponse {78  token: string;79  user: UserProfile;80  expiresAt: number;81}82 83export interface AuthService {84  login(email: string, password: string): Promise<AuthResponse>;85  register(data: RegisterData): Promise<AuthResponse>;86}87```88 89Both implementers import from the contract file but neither modifies it.90 91## Integration Patterns92 93### Vertical Slice94 95Each implementer builds a complete feature slice (UI + API + tests):96 97```98implementer-1: Login feature (login form + login API + login tests)99implementer-2: Register feature (register form + register API + register tests)100```101 102**Pros**: Each slice is independently testable, minimal integration needed.103**Cons**: May duplicate shared utilities, harder with tightly coupled features.104 105### Horizontal Layer106 107Each implementer builds one layer across all features:108 109```110implementer-1: All UI components (login form, register form, profile page)111implementer-2: All API endpoints (login, register, profile)112implementer-3: All tests (unit, integration, e2e)113```114 115**Pros**: Consistent patterns within each layer, natural specialization.116**Cons**: More integration points, layer 3 depends on layers 1 and 2.117 118### Hybrid119 120Mix vertical and horizontal based on coupling:121 122```123implementer-1: Login feature (vertical slice — UI + API + tests)124implementer-2: Shared auth infrastructure (horizontal — middleware, JWT utils, types)125```126 127**Best for**: Most real-world features with some shared infrastructure.128 129## Branch Management130 131### Single Branch Strategy132 133All implementers work on the same feature branch:134 135- Simple setup, no merge overhead136- Requires strict file ownership to avoid conflicts137- Best for: small teams (2-3), well-defined boundaries138 139### Multi-Branch Strategy140 141Each implementer works on a sub-branch:142 143```144feature/auth145  ├── feature/auth-login      (implementer-1)146  ├── feature/auth-register    (implementer-2)147  └── feature/auth-tests       (implementer-3)148```149 150- More isolation, explicit merge points151- Higher overhead, merge conflicts still possible in shared files152- Best for: larger teams (4+), complex features153 154## Troubleshooting155 156**Implementers are blocking each other waiting for shared code.**157Extract the shared piece into its own interface contract file owned by the team-lead and have implementers import from it. Neither implementer modifies the contract — they only implement against it.158 159**Merge conflicts appear even with clear ownership rules.**160A file was assigned to two agents, or a config/index file (e.g., `index.ts`, `__init__.py`) that auto-imports everything was modified by both. Designate one owner for all barrel/index files, or have the lead merge them at the end.161 162**An implementer finishes early but the integration step is blocked.**163Use a staging interface: the finished implementer writes a stub or mock of the downstream dependency so the other implementer can continue working. Replace with the real implementation at integration time.164 165**The feature decomposition turned out wrong mid-stream.**166Stop new work, have the lead redistribute files, and communicate the change via broadcast. Sunk cost on partially written code is acceptable — continuing with the wrong split is worse.167 168**Tests written by one implementer fail against code written by another.**169Interface contracts drifted: the implementer who owns the API changed a signature without notifying the test implementer. Enforce the rule that contract files require a broadcast before modification.170 171## Related Skills172 173- [team-composition-patterns](../team-composition-patterns/SKILL.md) — Choose the right team size and agent types before decomposing work174- [team-communication-protocols](../team-communication-protocols/SKILL.md) — Coordinate integration handoffs and plan approvals between implementers