{"kind":"Skill","metadata":{"namespace":"community","name":"ai-team-orchestration","version":"0.1.0"},"spec":{"description":"Bootstrap and run a multi-agent AI development team. Use when: starting a new software project with AI agents, setting up parallel dev/QA teams, creating sprint plans, writing brainstorm prompts with distinct agent voices, recovering a project workflow, or planning sprints.","files":{"SKILL.md":"---\nname: ai-team-orchestration\ndescription: 'Bootstrap and run a multi-agent AI development team. Use when: starting a new software project with AI agents, setting up parallel dev/QA teams, creating sprint plans, writing brainstorm prompts with distinct agent voices, recovering a project workflow, or planning sprints.'\n---\n\n# AI Team Orchestration\n\n## When to Use\n- Starting a new project that needs planning, development, testing, and deployment\n- Setting up parallel AI agent teams (dev, QA, DevOps)\n- Writing brainstorm prompts that produce real debate (not generic output)\n- Creating sprint plans with cross-chat context survival\n- Recovering from context overflow mid-sprint\n\n## Team Roles\n\n| Agent | Name | Role | Focus |\n|-------|------|------|-------|\n| Producer | **Remy** | Sprint planning, coordination, merging PRs | Scope control, handoffs, issue triage |\n| Product Designer | **Kira** | UX, mechanics, user experience | Fun factor, user flows, feature design |\n| Visual/Art Director | **Milo** | CSS, animations, visual identity | Design system, polish, accessibility |\n| Frontend Engineer | **Nova** | UI framework, state management, components | React/Vue/Svelte, client-side logic |\n| Backend Engineer | **Sage** | API, database, auth, security | Server-side logic, infrastructure |\n| DevOps Engineer | **Dash** | CI/CD, cloud deployment, pipelines | GitHub Actions, Azure/AWS/GCP |\n| QA Engineer | **Ivy** | E2E tests, automation, playtesting | Playwright/Cypress, bug filing, sign-off |\n\nCustomize names and roles for your project. Not every project needs all roles.\n\n## Chat Architecture\n\nThe human (CEO) is the message bus between parallel chats:\n\n```\n┌────────────────────────────────────────┐\n│  @ai-team-producer — Plans, merges     │\n│  NEVER writes code                     │\n└────────────────┬───────────────────────┘\n                 │ Human carries messages\n      ┌──────────┼──────────┐\n      ▼          ▼          ▼\n┌──────────┐ ┌────────┐ ┌────────┐\n│@ai-team  │ │@ai-team│ │DevOps  │\n│-dev      │ │-qa     │ │(on     │\n│          │ │        │ │demand) │\n│ Nova     │ │ Ivy    │ │        │\n│ Sage     │ │        │ │        │\n│ Milo     │ │        │ │        │\n│          │ │feature/│ │feature/│\n│ feature/ │ │qa-N    │ │devops-N│\n│ sprint-N │ └────────┘ └────────┘\n└──────────┘\n```\n\nEach team works in a **separate VS Code window** with its own clone:\n```bash\ngit clone \u003crepo\u003e project-dev    # Dev team\ngit clone \u003crepo\u003e project-qa     # QA\ngit clone \u003crepo\u003e project-devops # DevOps (only when needed)\n```\n\n## Project Bootstrap\n\n### 1. Create PROJECT_BRIEF.md\n\nThe single source of truth across all chats. See the [project brief template](./references/project-brief-template.md).\n\n**Required sections (do not abbreviate):**\n1. Project Overview\n2. Concept / Product Description\n3. Tech Stack\n4. Architecture (ASCII diagram)\n5. Key Files Map\n6. Team Roles\n7. Sprint Status (updated every sprint)\n8. Current State (rewritten every sprint)\n9. Security Rules\n10. How to Run Locally\n11. How to Deploy\n12. **Cross-Chat Handoff Protocol** — how context survives between chats\n13. **Bug \u0026 Fix Tracking** — GitHub Issues as single source of truth\n14. **Multi-Repo Setup** — separate clones, branch strategy, merge rules\n\n### 2. Run a Brainstorm\n\nSee the [brainstorm format](./references/brainstorm-format.md). Key: name each agent explicitly with distinct personality and perspective. Require at least 2 genuine disagreements to prevent groupthink.\n\n### 3. Create Sprint Plans\n\nSee the [sprint plan template](./references/sprint-plan-template.md). Every sprint gets:\n- `docs/sprint-N/plan.md` — prioritized tasks, success criteria\n- `docs/sprint-N/progress.md` — live tracker, enables recovery\n- `docs/sprint-N/done.md` — handoff doc written at sprint end\n\n### 4. Execute Sprints\n\n```\nRead PROJECT_BRIEF.md, then read docs/sprint-N/plan.md. Execute Sprint N.\n\nFirst: git pull origin main \u0026\u0026 git checkout -b feature/sprint-N\n\nClose GitHub Issues in commits: \"fix: description (Fixes #NN)\"\nUpdate docs/sprint-N/progress.md after each phase.\nWhen done, push and create PR: git push origin feature/sprint-N\nFollow Sections 12-14 of PROJECT_BRIEF.md.\n```\n\n### 5. QA Sign-off\n\nAfter dev merges, QA does a full playthrough:\n```\nRead PROJECT_BRIEF.md. You are Ivy (QA).\nSprint N is merged to main. Do full playthrough.\nFile bugs as GitHub Issues. Write docs/qa/sprint-N-signoff.md.\n```\n\n## Context Recovery\n\nWhen a chat gets long (\u003e100 messages), save state and start fresh:\n\n**Before closing:**\n1. Update `docs/sprint-N/progress.md` with current status\n2. Update `PROJECT_BRIEF.md` sections 7+8\n3. Write `docs/sprint-N/done.md`\n\n**Cold start prompt:**\n```\nRead PROJECT_BRIEF.md and docs/sprint-N/progress.md.\nContinue from where it left off.\n```\n\n## Anti-Patterns\n\nSee [anti-patterns reference](./references/anti-patterns.md) for the full list. Top 5:\n\n| Don't | Do Instead |\n|-------|------------|\n| Rebase feature branches | Merge (rebase loses commits) |\n| Producer writes code | Producer only plans, merges, files issues |\n| Batch \"fix everything\" commits | One commit per fix with issue reference |\n| Vague brainstorm prompts | Name each agent with distinct perspective |\n| Keep bugs only in chat | File GitHub Issues (chat context dies) |\n\n## Tips for Better Results\n\n- **\"Take your time, do it right\"** in prompts produces better output than rushing\n- **Test before merge** — you playtest, file issues, dev fixes, then merge\n- **Run team consiliums** before major sprints — each agent reviews the plan from their perspective\n- **Save lessons to memory** after every milestone\n","references/anti-patterns.md":"# Anti-Patterns\n\nLessons learned from real multi-agent projects. Each anti-pattern was encountered at least once and caused real problems.\n\n## Git \u0026 Branching\n\n| Don't | Do Instead | Why |\n|-------|------------|-----|\n| Rebase feature branches | Regular merge | Rebase rewrites history and loses commits. When multiple chats contribute to a branch, rebase causes cascading regressions. |\n| Squash merge PRs | Regular merge | Squash hides individual commits, making it impossible to revert a single fix. |\n| Use worktrees on shared branches | Separate clones | Worktrees share the git index. Parallel teams stepping on each other's staging area causes confusion. |\n| Push directly to main | Feature branch → PR → merge | Direct pushes bypass review and can't be reverted cleanly. |\n| Force push (`--force`) | Fix forward or revert | Force push destroys remote history that other teams may have pulled. |\n\n## Team Roles\n\n| Don't | Do Instead | Why |\n|-------|------------|-----|\n| 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. |\n| One agent does everything | Separate agents for dev, QA, coordination | Context isolation prevents cross-contamination. QA shouldn't have edit tools. |\n| Skip the brainstorm | Run brainstorm → plan → execute | Jumping straight to code produces generic results. Brainstorms surface edge cases early. |\n| 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. |\n\n## Sprint Management\n\n| Don't | Do Instead | Why |\n|-------|------------|-----|\n| 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. |\n| Keep bugs only in chat | File GitHub Issues | Chat context dies when the conversation ends. Issues persist across all chats and teams. |\n| 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. |\n| 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. |\n| 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. |\n\n## Testing \u0026 QA\n\n| Don't | Do Instead | Why |\n|-------|------------|-----|\n| Merge before testing | Playtest → file issues → fix → merge | Merging untested code creates a broken main branch. QA can't test against a moving target. |\n| QA modifies source code | QA only files issues, dev team fixes | QA fixes often miss context and introduce new bugs. Separation of concerns. |\n| Close issues without verification | Dev fixes → QA verifies → close | Self-closing issues skips verification. The fix might not actually work. |\n\n## Context \u0026 Communication\n\n| Don't | Do Instead | Why |\n|-------|------------|-----|\n| 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. |\n| Keep decisions in conversation | Write decisions to files | Decisions made in chat are lost when the chat closes. Write to docs/ or GitHub Issues. |\n| Relay raw error logs between teams | Summarize and file as GitHub Issue | Raw logs waste context tokens. Summarize: component, steps, expected, actual. |\n","references/brainstorm-format.md":"# Brainstorm Format\n\nUse 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.\n\n## Prompt Template\n\n```\nYou are orchestrating a brainstorm with the [PROJECT NAME] team.\nEach member has a DISTINCT voice, perspective, and expertise.\nThey should DEBATE, build on each other's ideas, and CHALLENGE weak concepts.\nThis is a creative session — no idea is too wild in Phase 1.\n\n### Kira (Product Designer)\n- Thinks about: user delight, accessibility, \"would this be fun?\"\n- Tendency: pushes for features that spark joy, pushes back on anything that feels like homework\n\n### Milo (Art/Visual Director)\n- Thinks about: visual identity, cohesion, \"does this look and feel right?\"\n- Tendency: wants everything beautiful, sometimes at odds with engineering feasibility\n\n### Nova (Frontend Engineer)\n- Thinks about: component architecture, state management, \"can we actually build this?\"\n- Tendency: pragmatic, flags scope risks, suggests simpler alternatives\n\n### Sage (Backend Engineer)\n- Thinks about: data model, API design, security, \"where do secrets live?\"\n- Tendency: security-first, sometimes over-engineers, good at spotting edge cases\n\n### Remy (Producer)\n- Thinks about: timeline, scope, \"will this ship?\"\n- Tendency: cuts scope aggressively, keeps the team focused on deliverables\n\n### Ivy (QA Engineer)\n- Thinks about: testability, edge cases, \"what breaks when the user does X?\"\n- Tendency: pessimistic about reliability, asks uncomfortable \"what if\" questions\n\nPhase 1 — Free Ideation:\nEach agent pitches 2-3 raw ideas from their perspective.\nWild ideas welcome. No filtering.\n\nPhase 2 — Discussion \u0026 Refinement:\nAgents debate, combine, and critique ideas.\nThey reference each other by name: \"Kira, that's great but...\"\nThey push back on weak points.\nAt least 2 genuine disagreements.\n\nPhase 3 — Final Pitches:\n3-5 polished concepts.\nEach concept includes: name, description, pros, cons, estimated effort.\nTeam vote with brief justification from each voter.\n\nOutput all phases as separate files:\n- docs/brainstorm/01-free-ideation.md\n- docs/brainstorm/02-discussion.md\n- docs/brainstorm/03-concept-[A/B/C...].md (one per concept)\n- docs/brainstorm/04-team-vote.md\n- docs/brainstorm/05-summary.md\n```\n\n## Tips\n\n- **Name each agent** — \"you are the full team\" produces bland consensus\n- **Define tendencies** — gives the LLM permission to disagree\n- **Require disagreements** — \"at least 2 genuine disagreements\" prevents groupthink\n- **Separate files** — forces structured output, makes it reviewable\n- **Customize personas** — adjust for your domain (e.g., replace Kira with a Data Scientist for ML projects)\n\n## Mini-Brainstorm (Quick Version)\n\nFor smaller decisions:\n\n```\nRun a team brainstorm about [TOPIC].\nEach agent speaks separately with their own perspective.\nThey should debate and disagree.\nWrite results to docs/[topic]-design.md.\n```\n\n## Team Consilium\n\nBefore major sprints, validate the plan:\n\n```\nRun a team consilium on the Sprint N plan.\nEach agent reviews from their perspective:\n- Kira: Is it fun / useful? Missing features?\n- Nova: Technically feasible? Scope risks?\n- Sage: Security concerns? API design issues?\n- Milo: Visual consistency? Design system gaps?\n- Ivy: Testable? Edge cases?\n- Remy: Timeline realistic? What to cut?\n\nFlag issues and suggest fixes.\n```\n","references/project-brief-template.md":"# PROJECT_BRIEF.md Template\n\nCopy 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.\n\n---\n\n```markdown\n# PROJECT_BRIEF.md — [Project Name]\n\n\u003e Last updated: [date] | Sprint [N] | Status: [In Progress / Complete]\n\n## 1. Project Overview\n\n[3-4 sentences describing what the project is, who it's for, and the core goal.]\n\n## 2. Concept / Product Description\n\n[Detailed description of the product — user flows, key features, narrative if applicable.]\n\n## 3. Tech Stack\n\n- **Frontend:** [framework, language, key libraries]\n- **Backend:** [runtime, framework, database]\n- **Hosting:** [platform, CDN, storage]\n- **Testing:** [test framework, E2E tool]\n- **CI/CD:** [pipeline tool]\n\n## 4. Architecture\n\n```\n┌─────────────────────────────────────────┐\n│              Frontend                    │\n│  [Main Component] → [Sub Components]    │\n└──────────────┬──────────────────────────┘\n               │ HTTPS\n┌──────────────▼──────────────────────────┐\n│              Backend API                 │\n│  [Endpoints and their purpose]          │\n└──────────────┬──────────────────────────┘\n               │\n┌──────────────▼──────────────────────────┐\n│              Storage / Database          │\n│  [Tables, collections, env vars]        │\n└─────────────────────────────────────────┘\n```\n\n## 5. Key Files Map\n\n| Area | Path | Contents |\n|------|------|----------|\n| Entry point | `src/main.tsx` | App bootstrap |\n| API | `api/src/` | Server-side logic |\n| Config | `api/src/config/` | Server-only configuration |\n| Tests | `tests/` | E2E and API tests |\n| Sprint docs | `docs/sprint-N/` | Plans, progress, done |\n\n## 6. Team Roles\n\n| Agent | Name | Role |\n|-------|------|------|\n| Producer | Remy | Sprint plans, coordination, merging |\n| Frontend | Nova | UI components, state, client logic |\n| Backend | Sage | API, auth, database, security |\n| Art/CSS | Milo | Visual design, animations, polish |\n| QA | Ivy | Testing, bug filing, sign-off |\n| Product | Kira | UX design, mechanics, feature specs |\n| DevOps | Dash | CI/CD, deployment, infrastructure |\n\n## 7. Sprint Status\n\n| Sprint | Name | Status | Scope |\n|--------|------|--------|-------|\n| 0 | Architecture | ✅ Done | Tech stack, project structure, design guide |\n| 1 | Core Features | 🔨 In Progress | [scope description] |\n\n## 8. Current State (rewrite every sprint)\n\n**What works:**\n- [List of working features]\n\n**What doesn't work yet:**\n- [Known issues]\n\n**What's next:**\n- [Next sprint goals]\n\n## 9. Security Rules\n\n1. Secrets live in environment variables only — never in code or git.\n2. [Auth approach]\n3. [Additional security rules]\n\n## 10. How to Run Locally\n\n```bash\nnpm install\ncd api \u0026\u0026 npm install\ncp api/local.settings.json.example api/local.settings.json\nnpm run dev:all\n```\n\n## 11. How to Deploy\n\n[Pipeline description, env var locations, deployment steps]\n\n## 12. Cross-Chat Handoff Protocol\n\nEvery sprint chat must do these before finishing:\n\n1. Write `docs/sprint-N/done.md` — what was built, what's not done, what needs manual setup, files changed/created\n2. Update PROJECT_BRIEF.md: Section 7 (mark sprint done) + Section 8 (rewrite current state)\n3. Commit all changes with descriptive message: `sprint-N: \u003csummary\u003e`\n\nThis 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.\n\n## 13. Bug \u0026 Fix Tracking\n\nBugs are tracked as GitHub Issues on the repo. Single source of truth for all teams.\n\n**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.\n\n**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`.\n\n**For DevOps:** File infrastructure issues with label `infra`.\n\n**For feature ideas:** add to `docs/ideas-backlog.md`.\n\n## 14. Multi-Repo Setup\n\nEach team works in their own separate clone of the repo. No worktrees. Everyone works on their own branch, pushes to origin, creates PRs.\n\n**Teams:**\n- Producer on `main` (coordination hub)\n- Dev Team on `feature/sprint-N`\n- QA on `feature/qa-N`\n- DevOps on `feature/devops-N` (only when needed)\n\n**Setup:**\n```bash\ngit clone \u003crepo\u003e \u003cfolder-name\u003e\ncd \u003cfolder-name\u003e\ngit checkout -b \u003cbranch-name\u003e\nnpm install\n```\n\n**Branch strategy:** Feature branches → PR → regular merge to main. Never push directly to main. Never squash. Never rebase feature branches (causes commit loss).\n```\n","references/sprint-plan-template.md":"# Sprint Plan Template\n\n## Plan File\n\nSave as `docs/sprint-N/plan.md`:\n\n```markdown\n# Sprint N — [Name]\n\n\u003e Sprint Goal: [one sentence describing the deliverable]\n\u003e Branch: feature/sprint-N\n\u003e Estimated effort: [time estimate]\n\n## Prioritized Task List\n\n| # | Task | Owner | Est | Description |\n|---|------|-------|-----|-------------|\n| 1 | [task] | Nova | 1h | [what to build] |\n| 2 | [task] | Sage | 2h | [what to build] |\n| 3 | [task] | Milo | 1h | [what to style] |\n\n## Work Schedule\n\n### Phase 1: [Name] (tasks 1-3)\n- Build [component]\n- Checkpoint commit after phase\n\n### Phase 2: [Name] (tasks 4-6)\n- Build [component]\n- Checkpoint commit after phase\n\n### Phase 3: Polish \u0026 Integration\n- Integration testing\n- Bug fixes\n- Final commit\n\n## Success Criteria\n\n- [ ] [Testable criterion 1]\n- [ ] [Testable criterion 2]\n- [ ] [Testable criterion 3]\n- [ ] All tests pass\n- [ ] No console errors\n\n## What's NOT in This Sprint\n\n| Feature | Reason |\n|---------|--------|\n| [cut feature] | [why — scope, complexity, not needed yet] |\n\n## Agent Prompt\n\n\u003e Read PROJECT_BRIEF.md, then read docs/sprint-N/plan.md. Execute Sprint N.\n\u003e\n\u003e First: git pull origin main \u0026\u0026 git checkout -b feature/sprint-N\n\u003e\n\u003e Close GitHub Issues in commits: \"fix: description (Fixes #NN)\"\n\u003e Update docs/sprint-N/progress.md after each phase.\n\u003e When done, push and create PR: git push origin feature/sprint-N\n\u003e Follow Sections 12-14 of PROJECT_BRIEF.md.\n```\n\n## Progress Tracker\n\nCreate `docs/sprint-N/progress.md` at sprint start:\n\n```markdown\n# Sprint N — Progress Tracker\n\n\u003e If context overflows, start a new chat:\n\u003e \"Read PROJECT_BRIEF.md and docs/sprint-N/progress.md.\n\u003e  Continue from where it left off.\"\n\n## Task Status\n\n| # | Task | Status | Notes |\n|---|------|--------|-------|\n| 1 | [task] | ⬜ Not started | |\n| 2 | [task] | 🔨 In progress | |\n| 3 | [task] | ✅ Done | |\n| 4 | [task] | ❌ Blocked | [reason] |\n\n## Bugs Found\n\n| # | Description | Severity | Status | Fix |\n|---|-------------|----------|--------|-----|\n| 1 | [bug] | blocker/major/minor | open/fixed | [commit or PR] |\n\n## Notes\n\n[Free-form notes about decisions, issues, or context for recovery]\n```\n\n## Done File\n\nWrite `docs/sprint-N/done.md` at sprint end:\n\n```markdown\n# Sprint N — Done\n\n## What Was Built\n- [Feature 1]\n- [Feature 2]\n\n## What's NOT Done\n- [Deferred item — why]\n\n## Files Changed/Created\n- `src/components/NewComponent.tsx` — [purpose]\n- `api/src/functions/newEndpoint.ts` — [purpose]\n\n## Manual Setup Required\n- [Any env vars, config, or manual steps needed]\n\n## Known Issues\n- [Issue — tracked as GitHub Issue #NN]\n```\n\n## QA Sign-off Template\n\n```markdown\n# QA Sprint N Sign-Off\n\nDate: [date]\nTester: Ivy (QA)\n\n## Test Results\n- Tests run: X\n- Tests passed: X\n- Tests failed: 0\n\n## Blockers\nNONE\n\n## Issues Filed\n- #NN — [description] (severity: minor)\n\n## Result\n✅ PASS — No blockers. Sprint N is ready to merge.\n```\n"},"import":{"commit_sha":"541b7819d8c3545c6df122491af4fa1eae415779","imported_at":"2026-05-18T20:05:35Z","license_text":"MIT License\n\nCopyright GitHub, Inc.\n\nPermission is hereby granted, free of charge, to any person obtaining a copy\nof this software and associated documentation files (the \"Software\"), to deal\nin the Software without restriction, including without limitation the rights\nto use, copy, modify, merge, publish, distribute, sublicense, and/or sell\ncopies of the Software, and to permit persons to whom the Software is\nfurnished to do so, subject to the following conditions:\n\nThe above copyright notice and this permission notice shall be included in all\ncopies or substantial portions of the Software.\n\nTHE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\nIMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\nFITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE\nAUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\nLIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,\nOUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE\nSOFTWARE.","owner":"github","repo":"github/awesome-copilot","source_url":"https://github.com/github/awesome-copilot/tree/541b7819d8c3545c6df122491af4fa1eae415779/plugins/ai-team-orchestration/skills/ai-team-orchestration"}},"content_hash":[32,122,99,186,179,203,222,9,198,73,2,190,146,179,108,122,140,121,199,242,41,149,94,225,214,222,100,119,2,30,56,110],"trust_level":"unsigned","yanked":false}