Parallel Feature Development
Run several feature tracks in parallel while keeping delivery predictable and integration risk low.
When to Use
- Multiple developers are shipping related features at the same time.
- Shared files or APIs create frequent merge conflicts.
- You need a repeatable process for syncing, testing, and integrating feature branches.
Workflow
Define feature tracks and owners, then map dependencies between tracks. Assign a single owner per track. Document which tracks depend on others (e.g., Feature B needs API changes from Feature A). Use a dependency graph or table; avoid implicit assumptions.
Choose a branch model and document merge direction. Options: (a) Feature flags + trunk-based: all work merges to main behind flags; partial integration happens in production. (b) Integration branch: feature branches merge to an integration/xyz branch for combined testing before merging to main. (c) Stacked PRs: small PRs stack on each other; each merges to main in sequence. Document which branches flow where and who merges when.
Identify shared touchpoints and conflict hotspots. List schemas, APIs, config files, and shared UI components. Use git log or conflict history to find files that change often across features-these are hotspots. Assign owners or split files to reduce contention.
Add integration checkpoints. Require daily (or twice-daily) rebase/merge from the base branch. Run smoke tests or a minimal integration suite after each sync. Catch conflicts early; do not defer integration until merge day.
Merge in dependency order and run final validation. Merge tracks that others depend on first. Run full end-to-end tests before release. Have a rollback plan for each track.
Decision Criteria: Integration Branch vs Feature Flags vs Stacked PRs
| Approach |
Best when |
Trade-offs |
| Feature flags |
Features can ship partially, teams want continuous delivery, low risk of breaking main |
Requires flag infrastructure; flags can accumulate if not cleaned up |
| Integration branch |
Features must be tested together before main, release cadence is batch-oriented |
Merge debt; integration branch can drift from main; extra merge at the end |
| Stacked PRs |
Small, incremental changes; each PR is independently shippable |
Requires discipline; base PRs must merge first; can block if reviews are slow |
Choose feature flags when you can ship incrementally and want to avoid long-lived branches. Choose integration branches when you need combined testing before main. Choose stacked PRs when changes are small and sequential.
Common Pitfalls
- Long-lived branches causing merge debt. Branches that live for weeks accumulate large merges and conflicts. Prefer short-lived branches, feature flags, or stacked PRs to keep branches small.
- Skipping integration checkpoints. Teams skip daily syncs when "things look fine," then hit big conflicts at merge time. Enforce checkpoints; treat them as non-negotiable.
- Implicit dependencies between feature tracks. Developers assume "Feature B will be ready" without documenting or sequencing. Make dependencies explicit and merge in order.
- Code freeze as a crutch. Freezing main before release hides integration problems instead of fixing them. Prefer continuous integration and feature flags so main stays stable.
Output Format
## Parallel Feature Plan
- Base branch: <branch>
- Branch model: <feature flags + trunk | integration branch | stacked PRs>
- Feature tracks:
- <feature A> | owner: <name> | depends on: <none|A|B> | target merge: <date>
- <feature B> | owner: <name> | depends on: <none|A|B> | target merge: <date>
## Shared Touchpoints and Conflict Hotspots
- Schemas/APIs: <paths, owners>
- Config: <paths, owners>
- Shared UI: <paths, owners>
- High-conflict files (from history): <paths, mitigation>
## Integration Checkpoints
- Sync cadence: <daily | twice daily>
- Sync action: <rebase | merge> from <base branch>
- Required checks after sync: <unit, integration, smoke, e2e>
- Escalation: <who to notify if sync fails>
## Merge Order and Validation
1. <branch> (rationale: no deps)
2. <branch> (rationale: depends on 1)
3. <branch>
- Final validation: <e2e suite, manual checks>
- Rollback plan: <per-track rollback steps>
## Risks and Mitigations
- <risk> -> <mitigation>
## Readiness Checklist
- [ ] Owners assigned for each feature track
- [ ] Dependencies between tracks explicit and agreed
- [ ] Shared touchpoints and hotspots documented with owners
- [ ] Branch model chosen with rationale
- [ ] Sync cadence and required checks agreed
- [ ] Merge order and rollback plan confirmed
Constraints
- Keep branch lifetimes short; long-lived branches increase conflict cost.
- Do not skip integration checkpoints, even when features look independent.
- Require explicit ownership for shared modules to avoid conflicting edits.
- Make dependencies between tracks explicit; never assume ordering.
- Avoid code freeze as primary integration strategy; prefer continuous integration.
1---2name: parallel-feature-development3description: Use this skill when coordinating multiple concurrent features, stacked PRs, branch strategy, dependency sequencing, integration checkpoints, feature flags, or release timing without destabilizing main.4---56# Parallel Feature Development78Run several feature tracks in parallel while keeping delivery predictable and integration risk low.910## When to Use1112- Multiple developers are shipping related features at the same time.13- Shared files or APIs create frequent merge conflicts.14- You need a repeatable process for syncing, testing, and integrating feature branches.1516## Workflow17181. **Define feature tracks and owners, then map dependencies between tracks.** Assign a single owner per track. Document which tracks depend on others (e.g., Feature B needs API changes from Feature A). Use a dependency graph or table; avoid implicit assumptions.19202. **Choose a branch model and document merge direction.** Options: (a) **Feature flags + trunk-based:** all work merges to `main` behind flags; partial integration happens in production. (b) **Integration branch:** feature branches merge to an `integration/xyz` branch for combined testing before merging to `main`. (c) **Stacked PRs:** small PRs stack on each other; each merges to `main` in sequence. Document which branches flow where and who merges when.21223. **Identify shared touchpoints and conflict hotspots.** List schemas, APIs, config files, and shared UI components. Use `git log` or conflict history to find files that change often across features-these are hotspots. Assign owners or split files to reduce contention.23244. **Add integration checkpoints.** Require daily (or twice-daily) rebase/merge from the base branch. Run smoke tests or a minimal integration suite after each sync. Catch conflicts early; do not defer integration until merge day.25265. **Merge in dependency order and run final validation.** Merge tracks that others depend on first. Run full end-to-end tests before release. Have a rollback plan for each track.2728## Decision Criteria: Integration Branch vs Feature Flags vs Stacked PRs2930| Approach | Best when | Trade-offs |31|----------|-----------|------------|32| **Feature flags** | Features can ship partially, teams want continuous delivery, low risk of breaking main | Requires flag infrastructure; flags can accumulate if not cleaned up |33| **Integration branch** | Features must be tested together before main, release cadence is batch-oriented | Merge debt; integration branch can drift from main; extra merge at the end |34| **Stacked PRs** | Small, incremental changes; each PR is independently shippable | Requires discipline; base PRs must merge first; can block if reviews are slow |3536Choose feature flags when you can ship incrementally and want to avoid long-lived branches. Choose integration branches when you need combined testing before main. Choose stacked PRs when changes are small and sequential.3738## Common Pitfalls3940- **Long-lived branches causing merge debt.** Branches that live for weeks accumulate large merges and conflicts. Prefer short-lived branches, feature flags, or stacked PRs to keep branches small.41- **Skipping integration checkpoints.** Teams skip daily syncs when "things look fine," then hit big conflicts at merge time. Enforce checkpoints; treat them as non-negotiable.42- **Implicit dependencies between feature tracks.** Developers assume "Feature B will be ready" without documenting or sequencing. Make dependencies explicit and merge in order.43- **Code freeze as a crutch.** Freezing main before release hides integration problems instead of fixing them. Prefer continuous integration and feature flags so main stays stable.4445## Output Format4647```markdown48## Parallel Feature Plan49- Base branch: <branch>50- Branch model: <feature flags + trunk | integration branch | stacked PRs>51- Feature tracks:52 - <feature A> | owner: <name> | depends on: <none|A|B> | target merge: <date>53 - <feature B> | owner: <name> | depends on: <none|A|B> | target merge: <date>5455## Shared Touchpoints and Conflict Hotspots56- Schemas/APIs: <paths, owners>57- Config: <paths, owners>58- Shared UI: <paths, owners>59- High-conflict files (from history): <paths, mitigation>6061## Integration Checkpoints62- Sync cadence: <daily | twice daily>63- Sync action: <rebase | merge> from <base branch>64- Required checks after sync: <unit, integration, smoke, e2e>65- Escalation: <who to notify if sync fails>6667## Merge Order and Validation681. <branch> (rationale: no deps)692. <branch> (rationale: depends on 1)703. <branch>71- Final validation: <e2e suite, manual checks>72- Rollback plan: <per-track rollback steps>7374## Risks and Mitigations75- <risk> -> <mitigation>7677## Readiness Checklist78- [ ] Owners assigned for each feature track79- [ ] Dependencies between tracks explicit and agreed80- [ ] Shared touchpoints and hotspots documented with owners81- [ ] Branch model chosen with rationale82- [ ] Sync cadence and required checks agreed83- [ ] Merge order and rollback plan confirmed84```8586## Constraints8788- Keep branch lifetimes short; long-lived branches increase conflict cost.89- Do not skip integration checkpoints, even when features look independent.90- Require explicit ownership for shared modules to avoid conflicting edits.91- Make dependencies between tracks explicit; never assume ordering.92- Avoid code freeze as primary integration strategy; prefer continuous integration.
ChatAndBuild