parallel-feature-development

Name: parallel-feature-development
Author: wshobson

38kstars4.1kforks

How to install parallel-feature-development?

wshobson/agents/parallel-feature-development

$npx -y skills add wshobson/agents --skill parallel-feature-development

Installs into the current project.

Summary

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 diff

Files · 1

View on GitHub

SKILL.md

1	# Parallel Feature Development
2
3	Strategies for decomposing features into parallel work streams, establishing file ownership boundaries, avoiding conflicts, and integrating results from multiple implementer agents.
4
5	## When to Use This Skill
6
7	- Decomposing a feature for parallel implementation
8	- Establishing file ownership boundaries between agents
9	- Designing interface contracts between parallel work streams
10	- Choosing integration strategies (vertical slice vs horizontal layer)
11	- Managing branch and merge workflows for parallel development
12
13	## File Ownership Strategies
14
15	### By Directory
16
17	Assign each implementer ownership of specific directories:
18
19	```
20	implementer-1: src/components/auth/
21	implementer-2: src/api/auth/
22	implementer-3: tests/auth/
23	```
24
25	Best for: Well-organized codebases with clear directory boundaries.
26
27	### By Module
28
29	Assign ownership of logical modules (which may span directories):
30
31	```
32	implementer-1: Authentication module (login, register, logout)
33	implementer-2: Authorization module (roles, permissions, guards)
34	```
35
36	Best for: Feature-oriented architectures, domain-driven design.
37
38	### By Layer
39
40	Assign ownership of architectural layers:
41
42	```
43	implementer-1: UI layer (components, styles, layouts)
44	implementer-2: Business logic layer (services, validators)
45	implementer-3: Data layer (models, repositories, migrations)
46	```
47
48	Best for: Traditional MVC/layered architectures.
49
50	## Conflict Avoidance Rules
51
52	### The Cardinal Rule
53
54	One owner per file. No file should be assigned to multiple implementers.
55
56	### When Files Must Be Shared
57
58	If a file genuinely needs changes from multiple implementers:
59
60	1. Designate a single owner — One implementer owns the file
61	2. Other implementers request changes — Message the owner with specific change requests
62	3. Owner applies changes sequentially — Prevents merge conflicts
63	4. Alternative: Extract interfaces — Create a separate interface file that the non-owner can import without modifying
64
65	### Interface Contracts
66
67	When implementers need to coordinate at boundaries:
68
69	```typescript
70	// src/types/auth-contract.ts (owned by team-lead, read-only for implementers)
71	export interface AuthResponse {
72	token: string;
73	user: UserProfile;
74	expiresAt: number;
75	}
76
77	export interface AuthService {
78	login(email: string, password: string): Promise<AuthResponse>;
79	register(data: RegisterData): Promise<AuthResponse>;
80	}
81	```
82
83	Both implementers import from the contract file but neither modifies it.
84
85	## Integration Patterns
86
87	### Vertical Slice
88
89	Each implementer builds a complete feature slice (UI + API + tests):
90
91	```
92	implementer-1: Login feature (login form + login API + login tests)
93	implementer-2: Register feature (register form + register API + register tests)
94	```
95
96	Pros: Each slice is independently testable, minimal integration needed.
97	Cons: May duplicate shared utilities, harder with tightly coupled features.
98
99	### Horizontal Layer
100
101	Each implementer builds one layer across all features:
102
103	```
104	implementer-1: All UI components (login form, register form, profile page)
105	implementer-2: All API endpoints (login, register, profile)
106	implementer-3: All tests (unit, integration, e2e)
107	```
108
109	Pros: Consistent patterns within each layer, natural specialization.
110	Cons: More integration points, layer 3 depends on layers 1 and 2.
111
112	### Hybrid
113
114	Mix vertical and horizontal based on coupling:
115
116	```
117	implementer-1: Login feature (vertical slice — UI + API + tests)
118	implementer-2: Shared auth infrastructure (horizontal — middleware, JWT utils, types)
119	```
120
121	Best for: Most real-world features with some shared infrastructure.
122
123	## Branch Management
124
125	### Single Branch Strategy
126
127	All implementers work on the same feature branch:
128
129	- Simple setup, no merge overhead
130	- Requires strict file ownership to avoid conflicts
131	- Best for: small teams (2-3), well-defined boundaries
132
133	### Multi-Branch Strategy
134
135	Each implementer works on a sub-branch:
136
137	```
138	feature/auth
139	├── feature/auth-login (implementer-1)
140	├── feature/auth-register (implementer-2)
141	└── feature/auth-tests (implementer-3)
142	```
143
144	- More isolation, explicit merge points
145	- Higher overhead, merge conflicts still possible in shared files
146	- Best for: larger teams (4+), complex features
147
148	## Troubleshooting
149
150	**Implementers are blocking each o

People who liked this also viewed

6 picks

Type

parallel-feature-development

38kstars4.1kforks

View on GitHub

How to install parallel-feature-development?

wshobson/agents/parallel-feature-development

$npx -y skills add wshobson/agents --skill parallel-feature-development

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Parallel Feature Development
2
3	Strategies for decomposing features into parallel work streams, establishing file ownership boundaries, avoiding conflicts, and integrating results from multiple implementer agents.
4
5	## When to Use This Skill
6
7	- Decomposing a feature for parallel implementation
8	- Establishing file ownership boundaries between agents
9	- Designing interface contracts between parallel work streams
10	- Choosing integration strategies (vertical slice vs horizontal layer)
11	- Managing branch and merge workflows for parallel development
12
13	## File Ownership Strategies
14
15	### By Directory
16
17	Assign each implementer ownership of specific directories:
18
19	```
20	implementer-1: src/components/auth/
21	implementer-2: src/api/auth/
22	implementer-3: tests/auth/
23	```
24
25	Best for: Well-organized codebases with clear directory boundaries.
26
27	### By Module
28
29	Assign ownership of logical modules (which may span directories):
30
31	```
32	implementer-1: Authentication module (login, register, logout)
33	implementer-2: Authorization module (roles, permissions, guards)
34	```
35
36	Best for: Feature-oriented architectures, domain-driven design.
37
38	### By Layer
39
40	Assign ownership of architectural layers:
41
42	```
43	implementer-1: UI layer (components, styles, layouts)
44	implementer-2: Business logic layer (services, validators)
45	implementer-3: Data layer (models, repositories, migrations)
46	```
47
48	Best for: Traditional MVC/layered architectures.
49
50	## Conflict Avoidance Rules
51
52	### The Cardinal Rule
53
54	One owner per file. No file should be assigned to multiple implementers.
55
56	### When Files Must Be Shared
57
58	If a file genuinely needs changes from multiple implementers:
59
60	1. Designate a single owner — One implementer owns the file
61	2. Other implementers request changes — Message the owner with specific change requests
62	3. Owner applies changes sequentially — Prevents merge conflicts
63	4. Alternative: Extract interfaces — Create a separate interface file that the non-owner can import without modifying
64
65	### Interface Contracts
66
67	When implementers need to coordinate at boundaries:
68
69	```typescript
70	// src/types/auth-contract.ts (owned by team-lead, read-only for implementers)
71	export interface AuthResponse {
72	token: string;
73	user: UserProfile;
74	expiresAt: number;
75	}
76
77	export interface AuthService {
78	login(email: string, password: string): Promise<AuthResponse>;
79	register(data: RegisterData): Promise<AuthResponse>;
80	}
81	```
82
83	Both implementers import from the contract file but neither modifies it.
84
85	## Integration Patterns
86
87	### Vertical Slice
88
89	Each implementer builds a complete feature slice (UI + API + tests):
90
91	```
92	implementer-1: Login feature (login form + login API + login tests)
93	implementer-2: Register feature (register form + register API + register tests)
94	```
95
96	Pros: Each slice is independently testable, minimal integration needed.
97	Cons: May duplicate shared utilities, harder with tightly coupled features.
98
99	### Horizontal Layer
100
101	Each implementer builds one layer across all features:
102
103	```
104	implementer-1: All UI components (login form, register form, profile page)
105	implementer-2: All API endpoints (login, register, profile)
106	implementer-3: All tests (unit, integration, e2e)
107	```
108
109	Pros: Consistent patterns within each layer, natural specialization.
110	Cons: More integration points, layer 3 depends on layers 1 and 2.
111
112	### Hybrid
113
114	Mix vertical and horizontal based on coupling:
115
116	```
117	implementer-1: Login feature (vertical slice — UI + API + tests)
118	implementer-2: Shared auth infrastructure (horizontal — middleware, JWT utils, types)
119	```
120
121	Best for: Most real-world features with some shared infrastructure.
122
123	## Branch Management
124
125	### Single Branch Strategy
126
127	All implementers work on the same feature branch:
128
129	- Simple setup, no merge overhead
130	- Requires strict file ownership to avoid conflicts
131	- Best for: small teams (2-3), well-defined boundaries
132
133	### Multi-Branch Strategy
134
135	Each implementer works on a sub-branch:
136
137	```
138	feature/auth
139	├── feature/auth-login (implementer-1)
140	├── feature/auth-register (implementer-2)
141	└── feature/auth-tests (implementer-3)
142	```
143
144	- More isolation, explicit merge points
145	- Higher overhead, merge conflicts still possible in shared files
146	- Best for: larger teams (4+), complex features
147
148	## Troubleshooting
149
150	**Implementers are blocking each o

People who liked this also viewed

6 picks

Type