mirror of
https://github.com/github/awesome-copilot.git
synced 2026-05-04 06:05:57 +00:00
Add ai-team-orchestration plugin: multi-agent dev team with Producer, Dev Team, QA agents (#1504)
* Add ai-team-orchestration plugin: multi-agent dev team with Producer, Dev Team, QA agents * fix: use kebab-case agent names to match filenames * fix: regenerate README after agent name change * fix: address Copilot review — add edit tools to Producer/QA, use GitHub closing keywords * fix: update agent tools to official VS Code tool set names Replace outdated/nonexistent tool names with current official tool sets: - Producer: search, read, edit, web (removed nonexistent githubRepo) - Dev Team: search, read, edit, execute, web (replaced runCommands, problems, usages, etc.) - QA: search, read, edit, execute, web (removed nonexistent findTestFiles, runTests) Ref: https://code.visualstudio.com/docs/copilot/reference/copilot-vscode-features#_chat-tools * fix: remove frontmatter from plugin README per reviewer feedback --------- Co-authored-by: Aaron Powell <me@aaron-powell.com>
This commit is contained in:
denis-a-evdokimov
committed by
GitHub
GitHub
parent
8aa465d4d2
commit
8cb29415be
48
skills/ai-team-orchestration/references/anti-patterns.md
Normal file
48
skills/ai-team-orchestration/references/anti-patterns.md
Normal file
@@ -0,0 +1,48 @@
|
||||
# Anti-Patterns
|
||||
|
||||
Lessons learned from real multi-agent projects. Each anti-pattern was encountered at least once and caused real problems.
|
||||
|
||||
## Git & Branching
|
||||
|
||||
| Don't | Do Instead | Why |
|
||||
|-------|------------|-----|
|
||||
| Rebase feature branches | Regular merge | Rebase rewrites history and loses commits. When multiple chats contribute to a branch, rebase causes cascading regressions. |
|
||||
| Squash merge PRs | Regular merge | Squash hides individual commits, making it impossible to revert a single fix. |
|
||||
| Use worktrees on shared branches | Separate clones | Worktrees share the git index. Parallel teams stepping on each other's staging area causes confusion. |
|
||||
| Push directly to main | Feature branch → PR → merge | Direct pushes bypass review and can't be reverted cleanly. |
|
||||
| Force push (`--force`) | Fix forward or revert | Force push destroys remote history that other teams may have pulled. |
|
||||
|
||||
## Team Roles
|
||||
|
||||
| Don't | Do Instead | Why |
|
||||
|-------|------------|-----|
|
||||
| Producer writes code | Producer only plans, merges, files issues | When the coordinator starts coding, they lose track of the big picture. Fixes in the producer chat often conflict with dev team work. |
|
||||
| One agent does everything | Separate agents for dev, QA, coordination | Context isolation prevents cross-contamination. QA shouldn't have edit tools. |
|
||||
| Skip the brainstorm | Run brainstorm → plan → execute | Jumping straight to code produces generic results. Brainstorms surface edge cases early. |
|
||||
| Vague brainstorm prompts ("you are the team") | Name each agent with distinct perspective | Named agents with defined tendencies produce real debate. Generic prompts produce bland consensus. |
|
||||
|
||||
## Sprint Management
|
||||
|
||||
| Don't | Do Instead | Why |
|
||||
|-------|------------|-----|
|
||||
| Batch "fix everything" commits | One commit per fix with issue reference | Batch commits make it impossible to track what was fixed. If one fix causes a regression, you can't revert just that fix. |
|
||||
| Keep bugs only in chat | File GitHub Issues | Chat context dies when the conversation ends. Issues persist across all chats and teams. |
|
||||
| Skip handoff docs (done.md) | Mandatory done.md + PROJECT_BRIEF update | Without handoff docs, the next chat starts blind. It may overwrite work or duplicate effort. |
|
||||
| Skip progress tracker | Update progress.md after each phase | Without a progress tracker, context overflow recovery is impossible. The new chat doesn't know where the old one left off. |
|
||||
| Rush the AI with time pressure | "Take your time, do it right" | Time pressure makes the LLM skip edge cases, write less tests, and produce lower quality code. "No rush" produces better results. |
|
||||
|
||||
## Testing & QA
|
||||
|
||||
| Don't | Do Instead | Why |
|
||||
|-------|------------|-----|
|
||||
| Merge before testing | Playtest → file issues → fix → merge | Merging untested code creates a broken main branch. QA can't test against a moving target. |
|
||||
| QA modifies source code | QA only files issues, dev team fixes | QA fixes often miss context and introduce new bugs. Separation of concerns. |
|
||||
| Close issues without verification | Dev fixes → QA verifies → close | Self-closing issues skips verification. The fix might not actually work. |
|
||||
|
||||
## Context & Communication
|
||||
|
||||
| Don't | Do Instead | Why |
|
||||
|-------|------------|-----|
|
||||
| Assume chats share memory | Files are the shared memory | Each chat is a fresh context. PROJECT_BRIEF.md and progress.md are the only things that survive. |
|
||||
| Keep decisions in conversation | Write decisions to files | Decisions made in chat are lost when the chat closes. Write to docs/ or GitHub Issues. |
|
||||
| Relay raw error logs between teams | Summarize and file as GitHub Issue | Raw logs waste context tokens. Summarize: component, steps, expected, actual. |
|
||||
94
skills/ai-team-orchestration/references/brainstorm-format.md
Normal file
94
skills/ai-team-orchestration/references/brainstorm-format.md
Normal file
@@ -0,0 +1,94 @@
|
||||
# Brainstorm Format
|
||||
|
||||
Use this format to produce real creative debate — not generic "the team agrees" output. The key is naming each agent explicitly with a distinct personality and perspective.
|
||||
|
||||
## Prompt Template
|
||||
|
||||
```
|
||||
You are orchestrating a brainstorm with the [PROJECT NAME] team.
|
||||
Each member has a DISTINCT voice, perspective, and expertise.
|
||||
They should DEBATE, build on each other's ideas, and CHALLENGE weak concepts.
|
||||
This is a creative session — no idea is too wild in Phase 1.
|
||||
|
||||
### Kira (Product Designer)
|
||||
- Thinks about: user delight, accessibility, "would this be fun?"
|
||||
- Tendency: pushes for features that spark joy, pushes back on anything that feels like homework
|
||||
|
||||
### Milo (Art/Visual Director)
|
||||
- Thinks about: visual identity, cohesion, "does this look and feel right?"
|
||||
- Tendency: wants everything beautiful, sometimes at odds with engineering feasibility
|
||||
|
||||
### Nova (Frontend Engineer)
|
||||
- Thinks about: component architecture, state management, "can we actually build this?"
|
||||
- Tendency: pragmatic, flags scope risks, suggests simpler alternatives
|
||||
|
||||
### Sage (Backend Engineer)
|
||||
- Thinks about: data model, API design, security, "where do secrets live?"
|
||||
- Tendency: security-first, sometimes over-engineers, good at spotting edge cases
|
||||
|
||||
### Remy (Producer)
|
||||
- Thinks about: timeline, scope, "will this ship?"
|
||||
- Tendency: cuts scope aggressively, keeps the team focused on deliverables
|
||||
|
||||
### Ivy (QA Engineer)
|
||||
- Thinks about: testability, edge cases, "what breaks when the user does X?"
|
||||
- Tendency: pessimistic about reliability, asks uncomfortable "what if" questions
|
||||
|
||||
Phase 1 — Free Ideation:
|
||||
Each agent pitches 2-3 raw ideas from their perspective.
|
||||
Wild ideas welcome. No filtering.
|
||||
|
||||
Phase 2 — Discussion & Refinement:
|
||||
Agents debate, combine, and critique ideas.
|
||||
They reference each other by name: "Kira, that's great but..."
|
||||
They push back on weak points.
|
||||
At least 2 genuine disagreements.
|
||||
|
||||
Phase 3 — Final Pitches:
|
||||
3-5 polished concepts.
|
||||
Each concept includes: name, description, pros, cons, estimated effort.
|
||||
Team vote with brief justification from each voter.
|
||||
|
||||
Output all phases as separate files:
|
||||
- docs/brainstorm/01-free-ideation.md
|
||||
- docs/brainstorm/02-discussion.md
|
||||
- docs/brainstorm/03-concept-[A/B/C...].md (one per concept)
|
||||
- docs/brainstorm/04-team-vote.md
|
||||
- docs/brainstorm/05-summary.md
|
||||
```
|
||||
|
||||
## Tips
|
||||
|
||||
- **Name each agent** — "you are the full team" produces bland consensus
|
||||
- **Define tendencies** — gives the LLM permission to disagree
|
||||
- **Require disagreements** — "at least 2 genuine disagreements" prevents groupthink
|
||||
- **Separate files** — forces structured output, makes it reviewable
|
||||
- **Customize personas** — adjust for your domain (e.g., replace Kira with a Data Scientist for ML projects)
|
||||
|
||||
## Mini-Brainstorm (Quick Version)
|
||||
|
||||
For smaller decisions:
|
||||
|
||||
```
|
||||
Run a team brainstorm about [TOPIC].
|
||||
Each agent speaks separately with their own perspective.
|
||||
They should debate and disagree.
|
||||
Write results to docs/[topic]-design.md.
|
||||
```
|
||||
|
||||
## Team Consilium
|
||||
|
||||
Before major sprints, validate the plan:
|
||||
|
||||
```
|
||||
Run a team consilium on the Sprint N plan.
|
||||
Each agent reviews from their perspective:
|
||||
- Kira: Is it fun / useful? Missing features?
|
||||
- Nova: Technically feasible? Scope risks?
|
||||
- Sage: Security concerns? API design issues?
|
||||
- Milo: Visual consistency? Design system gaps?
|
||||
- Ivy: Testable? Edge cases?
|
||||
- Remy: Timeline realistic? What to cut?
|
||||
|
||||
Flag issues and suggest fixes.
|
||||
```
|
||||
@@ -0,0 +1,147 @@
|
||||
# PROJECT_BRIEF.md Template
|
||||
|
||||
Copy this template to your project root and fill in every section. **Do not abbreviate sections 12-14** — they are critical for cross-chat context survival.
|
||||
|
||||
---
|
||||
|
||||
```markdown
|
||||
# PROJECT_BRIEF.md — [Project Name]
|
||||
|
||||
> Last updated: [date] | Sprint [N] | Status: [In Progress / Complete]
|
||||
|
||||
## 1. Project Overview
|
||||
|
||||
[3-4 sentences describing what the project is, who it's for, and the core goal.]
|
||||
|
||||
## 2. Concept / Product Description
|
||||
|
||||
[Detailed description of the product — user flows, key features, narrative if applicable.]
|
||||
|
||||
## 3. Tech Stack
|
||||
|
||||
- **Frontend:** [framework, language, key libraries]
|
||||
- **Backend:** [runtime, framework, database]
|
||||
- **Hosting:** [platform, CDN, storage]
|
||||
- **Testing:** [test framework, E2E tool]
|
||||
- **CI/CD:** [pipeline tool]
|
||||
|
||||
## 4. Architecture
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────┐
|
||||
│ Frontend │
|
||||
│ [Main Component] → [Sub Components] │
|
||||
└──────────────┬──────────────────────────┘
|
||||
│ HTTPS
|
||||
┌──────────────▼──────────────────────────┐
|
||||
│ Backend API │
|
||||
│ [Endpoints and their purpose] │
|
||||
└──────────────┬──────────────────────────┘
|
||||
│
|
||||
┌──────────────▼──────────────────────────┐
|
||||
│ Storage / Database │
|
||||
│ [Tables, collections, env vars] │
|
||||
└─────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
## 5. Key Files Map
|
||||
|
||||
| Area | Path | Contents |
|
||||
|------|------|----------|
|
||||
| Entry point | `src/main.tsx` | App bootstrap |
|
||||
| API | `api/src/` | Server-side logic |
|
||||
| Config | `api/src/config/` | Server-only configuration |
|
||||
| Tests | `tests/` | E2E and API tests |
|
||||
| Sprint docs | `docs/sprint-N/` | Plans, progress, done |
|
||||
|
||||
## 6. Team Roles
|
||||
|
||||
| Agent | Name | Role |
|
||||
|-------|------|------|
|
||||
| Producer | Remy | Sprint plans, coordination, merging |
|
||||
| Frontend | Nova | UI components, state, client logic |
|
||||
| Backend | Sage | API, auth, database, security |
|
||||
| Art/CSS | Milo | Visual design, animations, polish |
|
||||
| QA | Ivy | Testing, bug filing, sign-off |
|
||||
| Product | Kira | UX design, mechanics, feature specs |
|
||||
| DevOps | Dash | CI/CD, deployment, infrastructure |
|
||||
|
||||
## 7. Sprint Status
|
||||
|
||||
| Sprint | Name | Status | Scope |
|
||||
|--------|------|--------|-------|
|
||||
| 0 | Architecture | ✅ Done | Tech stack, project structure, design guide |
|
||||
| 1 | Core Features | 🔨 In Progress | [scope description] |
|
||||
|
||||
## 8. Current State (rewrite every sprint)
|
||||
|
||||
**What works:**
|
||||
- [List of working features]
|
||||
|
||||
**What doesn't work yet:**
|
||||
- [Known issues]
|
||||
|
||||
**What's next:**
|
||||
- [Next sprint goals]
|
||||
|
||||
## 9. Security Rules
|
||||
|
||||
1. Secrets live in environment variables only — never in code or git.
|
||||
2. [Auth approach]
|
||||
3. [Additional security rules]
|
||||
|
||||
## 10. How to Run Locally
|
||||
|
||||
```bash
|
||||
npm install
|
||||
cd api && npm install
|
||||
cp api/local.settings.json.example api/local.settings.json
|
||||
npm run dev:all
|
||||
```
|
||||
|
||||
## 11. How to Deploy
|
||||
|
||||
[Pipeline description, env var locations, deployment steps]
|
||||
|
||||
## 12. Cross-Chat Handoff Protocol
|
||||
|
||||
Every sprint chat must do these before finishing:
|
||||
|
||||
1. Write `docs/sprint-N/done.md` — what was built, what's not done, what needs manual setup, files changed/created
|
||||
2. Update PROJECT_BRIEF.md: Section 7 (mark sprint done) + Section 8 (rewrite current state)
|
||||
3. Commit all changes with descriptive message: `sprint-N: <summary>`
|
||||
|
||||
This is how context survives across chats. If skipped, the next chat starts blind and may overwrite or duplicate work. The repo is the shared memory — keep it accurate.
|
||||
|
||||
## 13. Bug & Fix Tracking
|
||||
|
||||
Bugs are tracked as GitHub Issues on the repo. Single source of truth for all teams.
|
||||
|
||||
**For QA:** File bugs as GitHub Issues with labels (`bug`, `severity:blocker/major/minor`). Include: component, steps to reproduce, expected vs actual. When no blockers found: write `docs/qa/sprint-N-signoff.md` with test count, pass rate, explicit "no blockers" statement.
|
||||
|
||||
**For Dev Team:** Check GitHub Issues before starting work. Fix blockers and majors before polish. Use GitHub closing keywords in commits: `fix: description (Fixes #42)`. For reference-only, use `Refs #42`.
|
||||
|
||||
**For DevOps:** File infrastructure issues with label `infra`.
|
||||
|
||||
**For feature ideas:** add to `docs/ideas-backlog.md`.
|
||||
|
||||
## 14. Multi-Repo Setup
|
||||
|
||||
Each team works in their own separate clone of the repo. No worktrees. Everyone works on their own branch, pushes to origin, creates PRs.
|
||||
|
||||
**Teams:**
|
||||
- Producer on `main` (coordination hub)
|
||||
- Dev Team on `feature/sprint-N`
|
||||
- QA on `feature/qa-N`
|
||||
- DevOps on `feature/devops-N` (only when needed)
|
||||
|
||||
**Setup:**
|
||||
```bash
|
||||
git clone <repo> <folder-name>
|
||||
cd <folder-name>
|
||||
git checkout -b <branch-name>
|
||||
npm install
|
||||
```
|
||||
|
||||
**Branch strategy:** Feature branches → PR → regular merge to main. Never push directly to main. Never squash. Never rebase feature branches (causes commit loss).
|
||||
```
|
||||
140
skills/ai-team-orchestration/references/sprint-plan-template.md
Normal file
140
skills/ai-team-orchestration/references/sprint-plan-template.md
Normal file
@@ -0,0 +1,140 @@
|
||||
# Sprint Plan Template
|
||||
|
||||
## Plan File
|
||||
|
||||
Save as `docs/sprint-N/plan.md`:
|
||||
|
||||
```markdown
|
||||
# Sprint N — [Name]
|
||||
|
||||
> Sprint Goal: [one sentence describing the deliverable]
|
||||
> Branch: feature/sprint-N
|
||||
> Estimated effort: [time estimate]
|
||||
|
||||
## Prioritized Task List
|
||||
|
||||
| # | Task | Owner | Est | Description |
|
||||
|---|------|-------|-----|-------------|
|
||||
| 1 | [task] | Nova | 1h | [what to build] |
|
||||
| 2 | [task] | Sage | 2h | [what to build] |
|
||||
| 3 | [task] | Milo | 1h | [what to style] |
|
||||
|
||||
## Work Schedule
|
||||
|
||||
### Phase 1: [Name] (tasks 1-3)
|
||||
- Build [component]
|
||||
- Checkpoint commit after phase
|
||||
|
||||
### Phase 2: [Name] (tasks 4-6)
|
||||
- Build [component]
|
||||
- Checkpoint commit after phase
|
||||
|
||||
### Phase 3: Polish & Integration
|
||||
- Integration testing
|
||||
- Bug fixes
|
||||
- Final commit
|
||||
|
||||
## Success Criteria
|
||||
|
||||
- [ ] [Testable criterion 1]
|
||||
- [ ] [Testable criterion 2]
|
||||
- [ ] [Testable criterion 3]
|
||||
- [ ] All tests pass
|
||||
- [ ] No console errors
|
||||
|
||||
## What's NOT in This Sprint
|
||||
|
||||
| Feature | Reason |
|
||||
|---------|--------|
|
||||
| [cut feature] | [why — scope, complexity, not needed yet] |
|
||||
|
||||
## Agent Prompt
|
||||
|
||||
> Read PROJECT_BRIEF.md, then read docs/sprint-N/plan.md. Execute Sprint N.
|
||||
>
|
||||
> First: git pull origin main && git checkout -b feature/sprint-N
|
||||
>
|
||||
> Close GitHub Issues in commits: "fix: description (Fixes #NN)"
|
||||
> Update docs/sprint-N/progress.md after each phase.
|
||||
> When done, push and create PR: git push origin feature/sprint-N
|
||||
> Follow Sections 12-14 of PROJECT_BRIEF.md.
|
||||
```
|
||||
|
||||
## Progress Tracker
|
||||
|
||||
Create `docs/sprint-N/progress.md` at sprint start:
|
||||
|
||||
```markdown
|
||||
# Sprint N — Progress Tracker
|
||||
|
||||
> If context overflows, start a new chat:
|
||||
> "Read PROJECT_BRIEF.md and docs/sprint-N/progress.md.
|
||||
> Continue from where it left off."
|
||||
|
||||
## Task Status
|
||||
|
||||
| # | Task | Status | Notes |
|
||||
|---|------|--------|-------|
|
||||
| 1 | [task] | ⬜ Not started | |
|
||||
| 2 | [task] | 🔨 In progress | |
|
||||
| 3 | [task] | ✅ Done | |
|
||||
| 4 | [task] | ❌ Blocked | [reason] |
|
||||
|
||||
## Bugs Found
|
||||
|
||||
| # | Description | Severity | Status | Fix |
|
||||
|---|-------------|----------|--------|-----|
|
||||
| 1 | [bug] | blocker/major/minor | open/fixed | [commit or PR] |
|
||||
|
||||
## Notes
|
||||
|
||||
[Free-form notes about decisions, issues, or context for recovery]
|
||||
```
|
||||
|
||||
## Done File
|
||||
|
||||
Write `docs/sprint-N/done.md` at sprint end:
|
||||
|
||||
```markdown
|
||||
# Sprint N — Done
|
||||
|
||||
## What Was Built
|
||||
- [Feature 1]
|
||||
- [Feature 2]
|
||||
|
||||
## What's NOT Done
|
||||
- [Deferred item — why]
|
||||
|
||||
## Files Changed/Created
|
||||
- `src/components/NewComponent.tsx` — [purpose]
|
||||
- `api/src/functions/newEndpoint.ts` — [purpose]
|
||||
|
||||
## Manual Setup Required
|
||||
- [Any env vars, config, or manual steps needed]
|
||||
|
||||
## Known Issues
|
||||
- [Issue — tracked as GitHub Issue #NN]
|
||||
```
|
||||
|
||||
## QA Sign-off Template
|
||||
|
||||
```markdown
|
||||
# QA Sprint N Sign-Off
|
||||
|
||||
Date: [date]
|
||||
Tester: Ivy (QA)
|
||||
|
||||
## Test Results
|
||||
- Tests run: X
|
||||
- Tests passed: X
|
||||
- Tests failed: 0
|
||||
|
||||
## Blockers
|
||||
NONE
|
||||
|
||||
## Issues Filed
|
||||
- #NN — [description] (severity: minor)
|
||||
|
||||
## Result
|
||||
✅ PASS — No blockers. Sprint N is ready to merge.
|
||||
```
|
||||
Reference in New Issue
Block a user