feat(agent-teams): add plugin for multi-agent team orchestration

New plugin with 7 presets (review, debug, feature, fullstack, research,
security, migration), 4 specialized agents, 7 slash commands, 6 skills
with reference docs, and Context7 MCP integration for research teams.

plugins/agent-teams/skills/parallel-feature-development/SKILL.md

@@ -0,0 +1,151 @@
+---
+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 features for parallel development, establishing file ownership boundaries, or managing integration between parallel work streams.
+---
+
+# Parallel Feature Development
+
+Strategies for decomposing features into parallel work streams, establishing file ownership boundaries, avoiding conflicts, and integrating results from multiple implementer agents.
+
+## When to Use This Skill
+
+- Decomposing a feature for parallel implementation
+- Establishing file ownership boundaries between agents
+- Designing interface contracts between parallel work streams
+- Choosing integration strategies (vertical slice vs horizontal layer)
+- Managing branch and merge workflows for parallel development
+
+## File Ownership Strategies
+
+### By Directory
+
+Assign each implementer ownership of specific directories:
+
+```
+implementer-1: src/components/auth/
+implementer-2: src/api/auth/
+implementer-3: tests/auth/
+```
+
+**Best for**: Well-organized codebases with clear directory boundaries.
+
+### By Module
+
+Assign ownership of logical modules (which may span directories):
+
+```
+implementer-1: Authentication module (login, register, logout)
+implementer-2: Authorization module (roles, permissions, guards)
+```
+
+**Best for**: Feature-oriented architectures, domain-driven design.
+
+### By Layer
+
+Assign ownership of architectural layers:
+
+```
+implementer-1: UI layer (components, styles, layouts)
+implementer-2: Business logic layer (services, validators)
+implementer-3: Data layer (models, repositories, migrations)
+```
+
+**Best for**: Traditional MVC/layered architectures.
+
+## Conflict Avoidance Rules
+
+### The Cardinal Rule
+
+**One owner per file.** No file should be assigned to multiple implementers.
+
+### When Files Must Be Shared
+
+If a file genuinely needs changes from multiple implementers:
+
+1. **Designate a single owner** — One implementer owns the file
+2. **Other implementers request changes** — Message the owner with specific change requests
+3. **Owner applies changes sequentially** — Prevents merge conflicts
+4. **Alternative: Extract interfaces** — Create a separate interface file that the non-owner can import without modifying
+
+### Interface Contracts
+
+When implementers need to coordinate at boundaries:
+
+```typescript
+// src/types/auth-contract.ts (owned by team-lead, read-only for implementers)
+export interface AuthResponse {
+  token: string;
+  user: UserProfile;
+  expiresAt: number;
+}
+
+export interface AuthService {
+  login(email: string, password: string): Promise<AuthResponse>;
+  register(data: RegisterData): Promise<AuthResponse>;
+}
+```
+
+Both implementers import from the contract file but neither modifies it.
+
+## Integration Patterns
+
+### Vertical Slice
+
+Each implementer builds a complete feature slice (UI + API + tests):
+
+```
+implementer-1: Login feature (login form + login API + login tests)
+implementer-2: Register feature (register form + register API + register tests)
+```
+
+**Pros**: Each slice is independently testable, minimal integration needed.
+**Cons**: May duplicate shared utilities, harder with tightly coupled features.
+
+### Horizontal Layer
+
+Each implementer builds one layer across all features:
+
+```
+implementer-1: All UI components (login form, register form, profile page)
+implementer-2: All API endpoints (login, register, profile)
+implementer-3: All tests (unit, integration, e2e)
+```
+
+**Pros**: Consistent patterns within each layer, natural specialization.
+**Cons**: More integration points, layer 3 depends on layers 1 and 2.
+
+### Hybrid
+
+Mix vertical and horizontal based on coupling:
+
+```
+implementer-1: Login feature (vertical slice — UI + API + tests)
+implementer-2: Shared auth infrastructure (horizontal — middleware, JWT utils, types)
+```
+
+**Best for**: Most real-world features with some shared infrastructure.
+
+## Branch Management
+
+### Single Branch Strategy
+
+All implementers work on the same feature branch:
+
+- Simple setup, no merge overhead
+- Requires strict file ownership to avoid conflicts
+- Best for: small teams (2-3), well-defined boundaries
+
+### Multi-Branch Strategy
+
+Each implementer works on a sub-branch:
+
+```
+feature/auth
+  ├── feature/auth-login      (implementer-1)
+  ├── feature/auth-register    (implementer-2)
+  └── feature/auth-tests       (implementer-3)
+```
+
+- More isolation, explicit merge points
+- Higher overhead, merge conflicts still possible in shared files
+- Best for: larger teams (4+), complex features

plugins/agent-teams/skills/parallel-feature-development/references/file-ownership.md

@@ -0,0 +1,80 @@
+# File Ownership Decision Framework
+
+How to assign file ownership when decomposing features for parallel development.
+
+## Ownership Decision Process
+
+### Step 1: Map All Files
+
+List every file that needs to be created or modified for the feature.
+
+### Step 2: Identify Natural Clusters
+
+Group files by:
+
+- Directory proximity (files in the same directory)
+- Functional relationship (files that import each other)
+- Layer membership (all UI files, all API files)
+
+### Step 3: Assign Clusters to Owners
+
+Each cluster becomes one implementer's ownership boundary:
+
+- No file appears in multiple clusters
+- Each cluster is internally cohesive
+- Cross-cluster dependencies are minimized
+
+### Step 4: Define Interface Points
+
+Where clusters interact, define:
+
+- Shared type definitions (owned by lead or a designated implementer)
+- API contracts (function signatures, request/response shapes)
+- Event contracts (event names and payload shapes)
+
+## Ownership by Project Type
+
+### React/Next.js Frontend
+
+```
+implementer-1: src/components/{feature}/   (UI components)
+implementer-2: src/hooks/{feature}/        (custom hooks, state)
+implementer-3: src/api/{feature}/          (API client, types)
+shared:        src/types/{feature}.ts      (owned by lead)
+```
+
+### Express/Fastify Backend
+
+```
+implementer-1: src/routes/{feature}.ts, src/controllers/{feature}.ts
+implementer-2: src/services/{feature}.ts, src/validators/{feature}.ts
+implementer-3: src/models/{feature}.ts, src/repositories/{feature}.ts
+shared:        src/types/{feature}.ts      (owned by lead)
+```
+
+### Full-Stack (Next.js)
+
+```
+implementer-1: app/{feature}/page.tsx, app/{feature}/components/
+implementer-2: app/api/{feature}/route.ts, lib/{feature}/
+implementer-3: tests/{feature}/
+shared:        types/{feature}.ts          (owned by lead)
+```
+
+### Python Django
+
+```
+implementer-1: {app}/views.py, {app}/urls.py, {app}/forms.py
+implementer-2: {app}/models.py, {app}/serializers.py, {app}/managers.py
+implementer-3: {app}/tests/
+shared:        {app}/types.py              (owned by lead)
+```
+
+## Conflict Resolution
+
+When two implementers need to modify the same file:
+
+1. **Preferred: Split the file** — Extract the shared concern into its own file
+2. **If can't split: Designate one owner** — The other implementer sends change requests
+3. **Last resort: Sequential access** — Implementer A finishes, then implementer B takes over
+4. **Never**: Let both modify the same file simultaneously

plugins/agent-teams/skills/parallel-feature-development/references/merge-strategies.md

@@ -0,0 +1,75 @@
+# Integration and Merge Strategies
+
+Patterns for integrating parallel work streams and resolving conflicts.
+
+## Integration Patterns
+
+### Pattern 1: Direct Integration
+
+All implementers commit to the same branch; integration happens naturally.
+
+```
+feature/auth ← implementer-1 commits
+             ← implementer-2 commits
+             ← implementer-3 commits
+```
+
+**When to use**: Small teams (2-3), strict file ownership (no conflicts expected).
+
+### Pattern 2: Sub-Branch Integration
+
+Each implementer works on a sub-branch; lead merges them sequentially.
+
+```
+feature/auth
+  ├── feature/auth-login     ← implementer-1
+  ├── feature/auth-register  ← implementer-2
+  └── feature/auth-tests     ← implementer-3
+```
+
+Merge order: follow dependency graph (foundation → dependent → integration).
+
+**When to use**: Larger teams (4+), overlapping concerns, need for review gates.
+
+### Pattern 3: Trunk-Based with Feature Flags
+
+All implementers commit to the main branch behind a feature flag.
+
+```
+main ← all implementers commit
+     ← feature flag gates new code
+```
+
+**When to use**: CI/CD environments, short-lived features, continuous deployment.
+
+## Integration Verification Checklist
+
+After all implementers complete:
+
+1. **Build check**: Does the code compile/bundle without errors?
+2. **Type check**: Do TypeScript/type annotations pass?
+3. **Lint check**: Does the code pass linting rules?
+4. **Unit tests**: Do all unit tests pass?
+5. **Integration tests**: Do cross-component tests pass?
+6. **Interface verification**: Do all interface contracts match their implementations?
+
+## Conflict Resolution
+
+### Prevention (Best)
+
+- Strict file ownership eliminates most conflicts
+- Interface contracts define boundaries before implementation
+- Shared type files are owned by the lead and modified sequentially
+
+### Detection
+
+- Git merge will report conflicts if they occur
+- TypeScript/lint errors indicate interface mismatches
+- Test failures indicate behavioral conflicts
+
+### Resolution Strategies
+
+1. **Contract wins**: If code doesn't match the interface contract, the code is wrong
+2. **Lead arbitrates**: The team lead decides which implementation to keep
+3. **Tests decide**: The implementation that passes tests is correct
+4. **Merge manually**: For complex conflicts, the lead merges by hand