mirror of
https://github.com/wshobson/agents.git
synced 2026-03-18 09:37:15 +00:00
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:
@@ -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
|
||||
@@ -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
|
||||
Reference in New Issue
Block a user