{"id":"parallel-feature-development","name":"parallel-feature-development","summary":"マルチエージェント実装のためのファイル所有権戦略、競合回避ルール、統合パターンと並行した機能開発を調整します。","body":"# Parallel Feature Development\n\nStrategies for decomposing features into parallel work streams, establishing file ownership boundaries, avoiding conflicts, and integrating results from multiple implementer agents.\n\n## When to Use This Skill\n\n- Decomposing a feature for parallel implementation\n- Establishing file ownership boundaries between agents\n- Designing interface contracts between parallel work streams\n- Choosing integration strategies (vertical slice vs horizontal layer)\n- Managing branch and merge workflows for parallel development\n\n## File Ownership Strategies\n\n### By Directory\n\nAssign each implementer ownership of specific directories:\n\n```\nimplementer-1: src/components/auth/\nimplementer-2: src/api/auth/\nimplementer-3: tests/auth/\n```\n\n**Best for**: Well-organized codebases with clear directory boundaries.\n\n### By Module\n\nAssign ownership of logical modules (which may span directories):\n\n```\nimplementer-1: Authentication module (login, register, logout)\nimplementer-2: Authorization module (roles, permissions, guards)\n```\n\n**Best for**: Feature-oriented architectures, domain-driven design.\n\n### By Layer\n\nAssign ownership of architectural layers:\n\n```\nimplementer-1: UI layer (components, styles, layouts)\nimplementer-2: Business logic layer (services, validators)\nimplementer-3: Data layer (models, repositories, migrations)\n```\n\n**Best for**: Traditional MVC/layered architectures.\n\n## Conflict Avoidance Rules\n\n### The Cardinal Rule\n\n**One owner per file.** No file should be assigned to multiple implementers.\n\n### When Files Must Be Shared\n\nIf a file genuinely needs changes from multiple implementers:\n\n1. **Designate a single owner** — One implementer owns the file\n2. **Other implementers request changes** — Message the owner with specific change requests\n3. **Owner applies changes sequentially** — Prevents merge conflicts\n4. **Alternative: Extract interfaces** — Create a separate interface file that the non-owner can import without modifying\n\n### Interface Contracts\n\nWhen implementers need to coordinate at boundaries:\n\n```typescript\n// src/types/auth-contract.ts (owned by team-lead, read-only for implementers)\nexport interface AuthResponse {\n  token: string;\n  user: UserProfile;\n  expiresAt: number;\n}\n\nexport interface AuthService {\n  login(email: string, password: string): Promise<AuthResponse>;\n  register(data: RegisterData): Promise<AuthResponse>;\n}\n```\n\nBoth implementers import from the contract file but neither modifies it.\n\n## Integration Patterns\n\n### Vertical Slice\n\nEach implementer builds a complete feature slice (UI + API + tests):\n\n```\nimplementer-1: Login feature (login form + login API + login tests)\nimplementer-2: Register feature (register form + register API + register tests)\n```\n\n**Pros**: Each slice is independently testable, minimal integration needed.\n**Cons**: May duplicate shared utilities, harder with tightly coupled features.\n\n### Horizontal Layer\n\nEach implementer builds one layer across all features:\n\n```\nimplementer-1: All UI components (login form, register form, profile page)\nimplementer-2: All API endpoints (login, register, profile)\nimplementer-3: All tests (unit, integration, e2e)\n```\n\n**Pros**: Consistent patterns within each layer, natural specialization.\n**Cons**: More integration points, layer 3 depends on layers 1 and 2.\n\n### Hybrid\n\nMix vertical and horizontal based on coupling:\n\n```\nimplementer-1: Login feature (vertical slice — UI + API + tests)\nimplementer-2: Shared auth infrastructure (horizontal — middleware, JWT utils, types)\n```\n\n**Best for**: Most real-world features with some shared infrastructure.\n\n## Branch Management\n\n### Single Branch Strategy\n\nAll implementers work on the same feature branch:\n\n- Simple setup, no merge overhead\n- Requires strict file ownership to avoid conflicts\n- Best for: small teams (2-3), well-defined boundaries\n\n### Multi-Branch Strategy\n\nEach implementer works on a sub-branch:\n\n```\nfeature/auth\n  ├── feature/auth-login      (implementer-1)\n  ├── feature/auth-register    (implementer-2)\n  └── feature/auth-tests       (implementer-3)\n```\n\n- More isolation, explicit merge points\n- Higher overhead, merge conflicts still possible in shared files\n- Best for: larger teams (4+), complex features\n\n## Troubleshooting\n\n**Implementers are blocking each other waiting for shared code.**\nExtract 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.\n\n**Merge conflicts appear even with clear ownership rules.**\nA 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.\n\n**An implementer finishes early but the integration step is blocked.**\nUse 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.\n\n**The feature decomposition turned out wrong mid-stream.**\nStop 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.\n\n**Tests written by one implementer fail against code written by another.**\nInterface 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.\n\n## Related Skills\n\n- [team-composition-patterns](../team-composition-patterns/SKILL.md) — Choose the right team size and agent types before decomposing work\n- [team-communication-protocols](../team-communication-protocols/SKILL.md) — Coordinate integration handoffs and plan approvals between implementers","author":"@wshobson","ownerProfile":null,"authorContacts":null,"sourceUrl":"https://github.com/wshobson/agents/tree/main/plugins/agent-teams/skills/parallel-feature-development","license":"MIT","category":"coding","lang":"en","tokens":1243,"stars":0,"calls30d":2,"claimed":false,"visibility":"public","origin":"crawler","version":"0.1.0","createdAt":"2026-08-22","updatedAt":"2026-08-22","files":[{"path":"references/file-ownership.md","size":2460,"sha256":"cf4fb139ad4284c6432527a5ec51b38037d06ca84c5cfba3ab7b88a47301fd24"},{"path":"references/merge-strategies.md","size":2342,"sha256":"39129b4947d1f50d85698000dfa464bd5cc42d73a214333fd36888b9a38d78b8"}],"requires":{"mcp":[],"tools":[]},"safety":{"flags":[],"scannedAt":"2026-08-22","hasScripts":false,"networkEndpoints":[]}}