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.
This commit is contained in:
Seth Hobson
2026-02-05 17:10:02 -05:00
parent 918a770990
commit 0752775afc
30 changed files with 3080 additions and 0 deletions

View File

@@ -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

View File

@@ -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