Parallel Feature Development
Unverified●25/40Claude Code◐PartialHas SKILL.md but declares no allowed-tools — Claude Code will ask for permission each time
Cursor◐PartialPlain prose you can paste in — but no Cursor rules file
Codex◐PartialPlain prose you can paste in — but no AGENTS.md
Gemini CLI◐PartialPlain prose you can paste in
Copilot◐PartialPlain prose you can paste in — but no Copilot instructions file
npx agentalley add parallel-feature-developmentWho is stuck, and on what
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.
The whole source
Frontmatter — 3 properties
| name | parallel-feature-development |
|---|---|
| description | 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. |
| version | 1.0.2 |
| 1 | --- |
| 2 | name: parallel-feature-development |
| 3 | description: 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.B1 — Line is 640 characters — unreadable by eye |
| 4 | version: 1.0.2 |
| 5 | ---A5 — No allowed-tools declared — no way to tell what this skill may touch |
| 6 | |
| 7 | # Parallel Feature Development |
| 8 | |
| 9 | Strategies 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 Skill |
| 12 | |
| 13 | - Decomposing a feature for parallel implementation |
| 14 | - Establishing file ownership boundaries between agents |
| 15 | - Designing interface contracts between parallel work streams |
| 16 | - Choosing integration strategies (vertical slice vs horizontal layer) |
| 17 | - Managing branch and merge workflows for parallel development |
| 18 | |
| 19 | ## File Ownership Strategies |
| 20 | |
| 21 | ### By Directory |
| 22 | |
| 23 | Assign each implementer ownership of specific directories: |
| 24 | |
| 25 | ``` |
| 26 | implementer-1: src/components/auth/ |
| 27 | implementer-2: src/api/auth/ |
| 28 | implementer-3: tests/auth/ |
| 29 | ``` |
| 30 | |
| 31 | **Best for**: Well-organized codebases with clear directory boundaries. |
| 32 | |
| 33 | ### By Module |
| 34 | |
| 35 | Assign ownership of logical modules (which may span directories): |
| 36 | |
| 37 | ``` |
| 38 | implementer-1: Authentication module (login, register, logout) |
| 39 | implementer-2: Authorization module (roles, permissions, guards) |
| 40 | ``` |
| 41 | |
| 42 | **Best for**: Feature-oriented architectures, domain-driven design. |
| 43 | |
| 44 | ### By Layer |
| 45 | |
| 46 | Assign ownership of architectural layers: |
| 47 | |
| 48 | ``` |
| 49 | implementer-1: UI layer (components, styles, layouts) |
| 50 | implementer-2: Business logic layer (services, validators) |
| 51 | implementer-3: Data layer (models, repositories, migrations) |
| 52 | ``` |
| 53 | |
| 54 | **Best for**: Traditional MVC/layered architectures. |
| 55 | |
| 56 | ## Conflict Avoidance Rules |
| 57 | |
| 58 | ### The Cardinal Rule |
| 59 | |
| 60 | **One owner per file.** No file should be assigned to multiple implementers. |
| 61 | |
| 62 | ### When Files Must Be Shared |
| 63 | |
| 64 | If a file genuinely needs changes from multiple implementers: |
| 65 | |
| 66 | 1. **Designate a single owner** — One implementer owns the file |
| 67 | 2. **Other implementers request changes** — Message the owner with specific change requests |
| 68 | 3. **Owner applies changes sequentially** — Prevents merge conflicts |
| 69 | 4. **Alternative: Extract interfaces** — Create a separate interface file that the non-owner can import without modifying |
| 70 | |
| 71 | ### Interface Contracts |
| 72 | |
| 73 | When implementers need to coordinate at boundaries: |
| 74 | |
| 75 | ```typescript |
| 76 | // src/types/auth-contract.ts (owned by team-lead, read-only for implementers) |
| 77 | export interface AuthResponse { |
| 78 | token: string; |
| 79 | user: UserProfile; |
| 80 | expiresAt: number; |
| 81 | } |
| 82 | |
| 83 | export interface AuthService { |
| 84 | login(email: string, password: string): Promise<AuthResponse>; |
| 85 | register(data: RegisterData): Promise<AuthResponse>; |
| 86 | } |
| 87 | ``` |
| 88 | |
| 89 | Both implementers import from the contract file but neither modifies it. |
| 90 | |
| 91 | ## Integration Patterns |
| 92 | |
| 93 | ### Vertical Slice |
| 94 | |
| 95 | Each implementer builds a complete feature slice (UI + API + tests): |
| 96 | |
| 97 | ``` |
| 98 | implementer-1: Login feature (login form + login API + login tests) |
| 99 | implementer-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 Layer |
| 106 | |
| 107 | Each implementer builds one layer across all features: |
| 108 | |
| 109 | ``` |
| 110 | implementer-1: All UI components (login form, register form, profile page) |
| 111 | implementer-2: All API endpoints (login, register, profile) |
| 112 | implementer-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 | ### Hybrid |
| 119 | |
| 120 | Mix vertical and horizontal based on coupling: |
| 121 | |
| 122 | ``` |
| 123 | implementer-1: Login feature (vertical slice — UI + API + tests) |
| 124 | implementer-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 Management |
| 130 | |
| 131 | ### Single Branch Strategy |
| 132 | |
| 133 | All implementers work on the same feature branch: |
| 134 | |
| 135 | - Simple setup, no merge overhead |
| 136 | - Requires strict file ownership to avoid conflicts |
| 137 | - Best for: small teams (2-3), well-defined boundaries |
| 138 | |
| 139 | ### Multi-Branch Strategy |
| 140 | |
| 141 | Each implementer works on a sub-branch: |
| 142 | |
| 143 | ``` |
| 144 | feature/auth |
| 145 | ├── feature/auth-login (implementer-1) |
| 146 | ├── feature/auth-register (implementer-2) |
| 147 | └── feature/auth-tests (implementer-3) |
| 148 | ``` |
| 149 | |
| 150 | - More isolation, explicit merge points |
| 151 | - Higher overhead, merge conflicts still possible in shared files |
| 152 | - Best for: larger teams (4+), complex features |
| 153 | |
| 154 | ## Troubleshooting |
| 155 | |
| 156 | **Implementers are blocking each other waiting for shared code.** |
| 157 | Extract 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.** |
| 160 | A 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.** |
| 163 | Use 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.** |
| 166 | Stop 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.** |
| 169 | Interface 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 Skills |
| 172 | |
| 173 | - [team-composition-patterns](../team-composition-patterns/SKILL.md) — Choose the right team size and agent types before decomposing work |
| 174 | - [team-communication-protocols](../team-communication-protocols/SKILL.md) — Coordinate integration handoffs and plan approvals between implementers |
| 175 |
Reviews
Installed this one?Write the first review and take the Trailblazer badge.
Alternatives
Task Coordination StrategiesDecompose complex tasks, design dependency graphs, and coordinate multi-agent work with proper task descriptions and workload balancing. Use this skill when breaking down work for agent teams, managing task dependencies, or monitoring team progress.◐◐◐◐◐●35/40Ebay Seller Tools·····●34/40Tough Decision Advisor: Every Angle ConsideredHand in a decision you're stuck on. Get back a clear breakdown of every angle — the trade-offs, the risks, the blind spot, and a recommended path.●····●32/40DHDNA Profiler — Cognitive Pattern ExtractionPaste any email, proposal, or note someone wrote, and get back a plain-language read on how they think, what drives their decisions, and how they communicate.●····●32/40