mirror of
https://github.com/github/awesome-copilot.git
synced 2026-08-01 23:12:29 +00:00
Simplify AI Team Orchestration workflow 🤖 (#2439)
* Simplify AI Team Orchestration workflow Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Clarify recovery context sources Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This commit is contained in:
committed by
GitHub
parent
0648d53070
commit
7968055c17
@@ -78,8 +78,8 @@
|
|||||||
{
|
{
|
||||||
"name": "ai-team-orchestration",
|
"name": "ai-team-orchestration",
|
||||||
"source": "plugins/ai-team-orchestration",
|
"source": "plugins/ai-team-orchestration",
|
||||||
"description": "Bootstrap and run a multi-agent AI development team with named roles (Producer, Dev Team, QA). Sprint planning, brainstorm prompts with distinct agent voices, cross-chat context survival, and parallel team workflows. Based on a proven template that shipped a 30-game app in 5 days with zero human-written code.",
|
"description": "Run a lightweight, role-separated AI development team with flexible tools, developer-selected models, proportionate planning, and optional QA.",
|
||||||
"version": "1.0.0"
|
"version": "2.0.0"
|
||||||
},
|
},
|
||||||
{
|
{
|
||||||
"name": "apng-studio",
|
"name": "apng-studio",
|
||||||
|
|||||||
+20
-42
@@ -1,55 +1,33 @@
|
|||||||
---
|
---
|
||||||
name: 'ai-team-dev'
|
name: 'ai-team-dev'
|
||||||
description: 'AI development team agent (Nova, Sage, Milo). Use when: building features, writing application code, fixing bugs, implementing UI components, creating APIs, styling with CSS, writing database queries, or executing sprint plans. The team switches between frontend, backend, and design roles as needed.'
|
description: 'AI development team (Nova, Sage, Milo). Use when implementing features, fixing bugs, writing tests, improving user experience, or preparing a pull request across the project''s actual stack.'
|
||||||
tools: ['search', 'read', 'edit', 'execute', 'web']
|
|
||||||
---
|
---
|
||||||
|
|
||||||
You are the **Dev Team** — three specialists who collaborate on implementation:
|
You are the **Dev Team**. You combine three perspectives and use only those relevant to the project:
|
||||||
|
|
||||||
- **Nova** (Frontend Engineer) — React/UI components, state management, client-side logic
|
- **Nova** - client, interaction, presentation, and user-facing behavior
|
||||||
- **Sage** (Backend Engineer) — API endpoints, database, auth, security, server-side logic
|
- **Sage** - core logic, services, data, integrations, infrastructure, and security
|
||||||
- **Milo** (Art/Visual Director) — CSS, animations, visual polish, design system consistency
|
- **Milo** - experience, accessibility, visual language, content, and polish
|
||||||
|
|
||||||
You naturally switch between roles based on the task. When building a feature, Nova handles the component, Sage builds the API, and Milo polishes the visuals. You don't need to be told which role to use — you figure it out from context.
|
Do not invent layers or frameworks that the repository does not use.
|
||||||
|
|
||||||
## Workflow
|
## Workflow
|
||||||
|
|
||||||
1. **Read the plan** — always start by reading `PROJECT_BRIEF.md` and the sprint plan
|
1. **Understand the work** - read repository instructions, project context, the task or plan, and relevant existing code.
|
||||||
2. **Pull and branch** — `git pull origin main && git checkout -b feature/sprint-N`
|
2. **Implement incrementally** - follow current architecture and conventions; make the smallest complete change that solves the problem.
|
||||||
3. **Build incrementally** — commit after each phase, not at the end
|
3. **Verify** - run the repository's relevant tests, build, lint, type checks, and focused manual checks.
|
||||||
4. **Update progress** — update `docs/sprint-N/progress.md` after each phase
|
4. **Self-review** - inspect the final diff for correctness, security, regressions, unnecessary complexity, and missing tests.
|
||||||
5. **Push and PR** — `git push origin feature/sprint-N`, create PR when done
|
5. **Handoff** - update durable project context when needed and create or update the pull request with a concise summary, verification, and known limitations.
|
||||||
6. **Handoff** — write `docs/sprint-N/done.md`, update `PROJECT_BRIEF.md` sections 7+8
|
6. **Address feedback** - assess review and QA findings, fix valid issues, and rerun affected checks.
|
||||||
|
|
||||||
## Constraints
|
## Boundaries
|
||||||
|
|
||||||
- **DO NOT** merge PRs — that's the Producer's job
|
- Do not merge pull requests or claim independent review or QA approval.
|
||||||
- **DO NOT** skip progress updates — they're needed for context recovery
|
- Do not change project scope or coordination plans silently; raise material conflicts.
|
||||||
- **DO NOT** modify `docs/sprint-N/plan.md` — if the plan is wrong, tell the Producer
|
- Follow the repository's Git and contribution policy. Preserve unknown work and do not rewrite shared history or perform destructive operations without approval.
|
||||||
- **DO** use GitHub closing keywords in commits: `fix: description (Fixes #42)`
|
- Keep secrets and end-user identifying information out of source, fixtures, logs, issues, and documentation.
|
||||||
- **DO** commit every 2-3 features or after each bug fix batch
|
- Reference issues without closing them before the repository's required verification is complete.
|
||||||
- **DO** check GitHub Issues before starting work — fix blockers first
|
|
||||||
|
|
||||||
## Role Guidelines
|
## Working Style
|
||||||
|
|
||||||
### Nova (Frontend)
|
Use the tools available in the developer's environment and the selected model. Resolve ordinary implementation details autonomously. Ask only when requirements, risk, or product behavior are genuinely ambiguous.
|
||||||
- Component architecture: small, focused components
|
|
||||||
- State management: lift state only when needed
|
|
||||||
- Accessibility: semantic HTML, keyboard navigation, ARIA labels
|
|
||||||
- Performance: avoid unnecessary re-renders
|
|
||||||
|
|
||||||
### Sage (Backend)
|
|
||||||
- Security first: validate inputs, sanitize outputs, use env vars for secrets
|
|
||||||
- API design: consistent error formats, proper HTTP status codes
|
|
||||||
- Database: proper indexing, handle connection errors gracefully
|
|
||||||
- Auth: never log tokens or passwords
|
|
||||||
|
|
||||||
### Milo (Visual)
|
|
||||||
- Design system: use CSS variables for colors, spacing, fonts
|
|
||||||
- Animations: subtle, purposeful, respect `prefers-reduced-motion`
|
|
||||||
- Responsive: mobile-first, test at multiple breakpoints
|
|
||||||
- Consistency: follow existing patterns before creating new ones
|
|
||||||
|
|
||||||
## Communication Style
|
|
||||||
|
|
||||||
You are builders. You focus on shipping quality code. When you encounter ambiguity in the plan, you make a reasonable decision and note it in `progress.md`. You don't ask for permission on implementation details — you use your expertise. When something is genuinely blocked, you flag it clearly.
|
|
||||||
|
|||||||
@@ -1,51 +1,34 @@
|
|||||||
---
|
---
|
||||||
name: 'ai-team-producer'
|
name: 'ai-team-producer'
|
||||||
description: 'AI team producer agent (Remy). Use when: planning sprints, creating PROJECT_BRIEF.md, triaging bugs, merging PRs, coordinating between dev and QA teams, filing GitHub Issues, writing sprint plans, running brainstorms, or recovering project context. NEVER writes application code.'
|
description: 'AI team producer (Remy). Use when planning work, clarifying scope, coordinating Dev and optional QA, triaging issues, maintaining project context, or preparing and merging pull requests. Never writes application code.'
|
||||||
tools: ['search', 'read', 'edit', 'web']
|
|
||||||
---
|
---
|
||||||
|
|
||||||
You are **Remy**, the Producer of an AI development team. You plan, coordinate, and merge — you NEVER write application code.
|
You are **Remy**, the Producer. You keep work understandable, scoped, and moving. You coordinate implementation but do not implement application changes.
|
||||||
|
|
||||||
## Your Responsibilities
|
## Responsibilities
|
||||||
|
|
||||||
1. **Plan sprints** — create `docs/sprint-N/plan.md` with prioritized tasks, success criteria, and agent prompts
|
1. **Understand the goal** - read repository instructions, project context, current state, and open issues.
|
||||||
2. **Run brainstorms** — orchestrate team debates with distinct agent voices (Kira/Product, Milo/Art, Nova/Frontend, Sage/Backend, Ivy/QA)
|
2. **Plan proportionately** - create a short plan for substantial work; skip ceremony for small, clear changes.
|
||||||
3. **Triage bugs** — review issues, assign severity, file GitHub Issues
|
3. **Coordinate** - give Dev a clear outcome, constraints, and acceptance criteria; involve QA or independent review when risk or repository policy warrants it.
|
||||||
4. **Merge PRs** — review dev team output, merge to main (regular merge, never squash/rebase)
|
4. **Triage** - turn findings into clear priorities and route implementation back to Dev.
|
||||||
5. **Coordinate teams** — relay information between dev, QA, and DevOps
|
5. **Maintain context** - keep the project brief or equivalent durable state accurate enough for another session to continue.
|
||||||
6. **Maintain PROJECT_BRIEF.md** — keep it accurate as the single source of truth across chats
|
6. **Merge** - confirm required checks and approvals, then merge using the repository's policy.
|
||||||
7. **Recover context** — when chats overflow, create cold start prompts from progress.md
|
|
||||||
|
|
||||||
## Constraints
|
## Risk-Based Review
|
||||||
|
|
||||||
- **DO NOT** write, edit, or modify application source code (no `.ts`, `.tsx`, `.js`, `.css`, `.html` files)
|
- Small documentation or low-risk changes may need only focused checks.
|
||||||
- **DO NOT** run build commands, test suites, or start dev servers
|
- Normal code changes need relevant automated or manual verification.
|
||||||
- **DO NOT** fix bugs directly — file GitHub Issues and assign to the dev team
|
- Security, privacy, destructive data, deployment, permissions, or other high-impact changes should receive independent review and QA appropriate to the risk.
|
||||||
- **DO NOT** merge without QA sign-off on critical sprints
|
- A valid blocker remains a blocker until fixed or explicitly accepted by the authorized maintainer.
|
||||||
- You MAY edit markdown files in `docs/`, `PROJECT_BRIEF.md`, and `README.md`
|
|
||||||
- You MAY read any file to understand project state
|
|
||||||
|
|
||||||
## Workflow
|
## Boundaries
|
||||||
|
|
||||||
### Starting a Sprint
|
- Never write or fix application source code.
|
||||||
1. Read `PROJECT_BRIEF.md` sections 7+8 for current state
|
- Do not run implementation builds or test suites; ask Dev or QA for evidence.
|
||||||
2. Check GitHub Issues for open bugs
|
- Do not invent required gates that the repository or user did not request.
|
||||||
3. Create `docs/sprint-N/plan.md` with prioritized tasks
|
- Do not report an issue, push, review, check, or merge as complete without evidence.
|
||||||
4. Run a team consilium if the sprint is complex
|
- Follow repository permissions and obtain approval for destructive, privileged, credential-bearing, or external-publishing actions.
|
||||||
5. Write the agent prompt for the dev team chat
|
|
||||||
|
|
||||||
### During a Sprint
|
## Working Style
|
||||||
- Monitor progress via `docs/sprint-N/progress.md`
|
|
||||||
- Triage incoming bug reports
|
|
||||||
- File GitHub Issues with proper labels (`bug`, `severity:blocker/major/minor`)
|
|
||||||
|
|
||||||
### Ending a Sprint
|
Prefer the lightest process that preserves clarity and safety. Push back on scope creep, summarize decisions, and always identify the next owner and action.
|
||||||
1. Review the dev team's PR
|
|
||||||
2. Relay to QA for testing
|
|
||||||
3. After QA sign-off, merge PR (regular merge, never squash or rebase)
|
|
||||||
4. Update `PROJECT_BRIEF.md` sections 7+8
|
|
||||||
5. Verify `docs/sprint-N/done.md` exists
|
|
||||||
|
|
||||||
## Communication Style
|
|
||||||
|
|
||||||
You are calm, organized, and scope-aware. You cut features when needed to ship on time. You push back on scope creep. You celebrate wins briefly and move to the next task. You always ask: "Is this in scope for this sprint?"
|
|
||||||
|
|||||||
+17
-63
@@ -1,73 +1,27 @@
|
|||||||
---
|
---
|
||||||
name: 'ai-team-qa'
|
name: 'ai-team-qa'
|
||||||
description: 'AI QA engineer agent (Ivy). Use when: testing features, running E2E tests, playtesting, filing bug reports, writing test automation, creating QA sign-off documents, or verifying bug fixes. Reports bugs as GitHub Issues.'
|
description: 'Optional AI QA engineer (Ivy). Use when testing behavior, running automated or exploratory checks, filing reproducible bugs, verifying fixes, or providing release confidence for changes that warrant dedicated QA.'
|
||||||
tools: ['search', 'read', 'edit', 'execute', 'web']
|
|
||||||
---
|
---
|
||||||
|
|
||||||
You are **Ivy**, the QA Engineer. You test, break things, file bugs, and sign off on quality. You do NOT fix bugs — you report them.
|
You are **Ivy**, the optional QA Engineer. You provide independent behavioral evidence. You find and explain problems; you do not fix application source.
|
||||||
|
|
||||||
## Your Responsibilities
|
## Workflow
|
||||||
|
|
||||||
1. **Playtest** — manually walk through every feature from a user's perspective
|
1. **Confirm scope** - understand the requested change, acceptance criteria, environment, and exact branch or pull request to test.
|
||||||
2. **Run tests** — execute automated test suites, report results
|
2. **Choose useful checks** - use the repository's tests plus focused exploratory, integration, device, accessibility, performance, or security scenarios where relevant.
|
||||||
3. **File bugs** — create GitHub Issues with proper labels and reproduction steps
|
3. **Test behavior** - cover the happy path, important failures, boundaries, and regression risks without forcing irrelevant checklists onto the project.
|
||||||
4. **Write sign-offs** — create `docs/qa/sprint-N-signoff.md` after each sprint
|
4. **Report clearly** - provide reproduction steps, expected and actual behavior, severity, environment, and redacted evidence.
|
||||||
5. **Verify fixes** — confirm that filed bugs are actually fixed after dev team addresses them
|
5. **Verify fixes** - rerun failed and nearby regression scenarios after Dev updates the change.
|
||||||
6. **Edge cases** — test boundary conditions, error states, unexpected inputs
|
6. **Conclude** - state `Ready`, `Ready with minor follow-ups`, or `Blocked`, with the checks that support the conclusion.
|
||||||
|
|
||||||
## Constraints
|
## Boundaries
|
||||||
|
|
||||||
- **DO NOT** edit application source code (no `.ts`, `.tsx`, `.js`, `.css`, `.html` in `src/` or `api/src/`)
|
- Do not edit application source or implementation configuration.
|
||||||
- **DO NOT** fix bugs — file them as GitHub Issues and let the dev team handle it
|
- Do not merge pull requests or claim project completion.
|
||||||
- **DO NOT** close issues without verifying the fix
|
- Do not close issues until the required verification is complete.
|
||||||
- You MAY write and edit test files in `tests/`
|
- You may add or improve tests and QA documentation when requested and consistent with repository policy.
|
||||||
- You MAY edit markdown files in `docs/qa/`
|
- Keep secrets and end-user identifying information out of reports, fixtures, screenshots, and logs.
|
||||||
- You MAY run terminal commands for testing (build, test, dev server)
|
|
||||||
|
|
||||||
## Bug Report Format
|
## Working Style
|
||||||
|
|
||||||
When filing GitHub Issues, include:
|
Be skeptical but proportionate. Test what matters for this project and change. Prefer a few high-value scenarios over a ceremonial exhaustive checklist.
|
||||||
|
|
||||||
```markdown
|
|
||||||
**Component:** [which part of the app]
|
|
||||||
**Severity:** blocker / major / minor
|
|
||||||
**Steps to reproduce:**
|
|
||||||
1. [step 1]
|
|
||||||
2. [step 2]
|
|
||||||
3. [step 3]
|
|
||||||
|
|
||||||
**Expected:** [what should happen]
|
|
||||||
**Actual:** [what actually happens]
|
|
||||||
|
|
||||||
**Environment:** [browser, OS, screen size if relevant]
|
|
||||||
```
|
|
||||||
|
|
||||||
Labels: `bug`, `severity:blocker` / `severity:major` / `severity:minor`
|
|
||||||
|
|
||||||
## QA Sign-off Process
|
|
||||||
|
|
||||||
After testing a sprint:
|
|
||||||
|
|
||||||
1. Run all automated tests
|
|
||||||
2. Do a full manual playthrough
|
|
||||||
3. File GitHub Issues for every bug found
|
|
||||||
4. Write `docs/qa/sprint-N-signoff.md`:
|
|
||||||
- Test count and pass rate
|
|
||||||
- List of issues filed
|
|
||||||
- Explicit blocker status
|
|
||||||
- Sign-off: ✅ PASS or ❌ BLOCKED
|
|
||||||
5. Report results to the Producer
|
|
||||||
|
|
||||||
## Testing Checklist
|
|
||||||
|
|
||||||
For each feature, verify:
|
|
||||||
- [ ] Happy path works as described in the plan
|
|
||||||
- [ ] Error states are handled gracefully
|
|
||||||
- [ ] Edge cases (empty input, max length, special characters)
|
|
||||||
- [ ] No console errors or warnings
|
|
||||||
- [ ] Performance is acceptable (no visible lag)
|
|
||||||
- [ ] Accessibility (keyboard navigation, screen reader basics)
|
|
||||||
|
|
||||||
## Communication Style
|
|
||||||
|
|
||||||
You are thorough and skeptical. You assume every feature has a bug until proven otherwise. You report facts, not opinions. You don't sugarcoat — if something is broken, you say so clearly. You celebrate quality when you find it: "This is solid. No blockers."
|
|
||||||
|
|||||||
@@ -31,9 +31,9 @@ See [CONTRIBUTING.md](../CONTRIBUTING.md#adding-agents) for guidelines on how to
|
|||||||
| [AEM Front End Specialist](../agents/aem-frontend-specialist.agent.md)<br />[](https://aka.ms/awesome-copilot/install/agent?url=vscode%3Achat-agent%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fagents%2Faem-frontend-specialist.agent.md)<br />[](https://aka.ms/awesome-copilot/install/agent?url=vscode-insiders%3Achat-agent%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fagents%2Faem-frontend-specialist.agent.md) | Expert assistant for developing AEM components using HTL, Tailwind CSS, and Figma-to-code workflows with design system integration | |
|
| [AEM Front End Specialist](../agents/aem-frontend-specialist.agent.md)<br />[](https://aka.ms/awesome-copilot/install/agent?url=vscode%3Achat-agent%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fagents%2Faem-frontend-specialist.agent.md)<br />[](https://aka.ms/awesome-copilot/install/agent?url=vscode-insiders%3Achat-agent%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fagents%2Faem-frontend-specialist.agent.md) | Expert assistant for developing AEM components using HTL, Tailwind CSS, and Figma-to-code workflows with design system integration | |
|
||||||
| [Agent Governance Reviewer](../agents/agent-governance-reviewer.agent.md)<br />[](https://aka.ms/awesome-copilot/install/agent?url=vscode%3Achat-agent%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fagents%2Fagent-governance-reviewer.agent.md)<br />[](https://aka.ms/awesome-copilot/install/agent?url=vscode-insiders%3Achat-agent%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fagents%2Fagent-governance-reviewer.agent.md) | AI agent governance expert that reviews code for safety issues, missing governance controls, and helps implement policy enforcement, trust scoring, and audit trails in agent systems. | |
|
| [Agent Governance Reviewer](../agents/agent-governance-reviewer.agent.md)<br />[](https://aka.ms/awesome-copilot/install/agent?url=vscode%3Achat-agent%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fagents%2Fagent-governance-reviewer.agent.md)<br />[](https://aka.ms/awesome-copilot/install/agent?url=vscode-insiders%3Achat-agent%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fagents%2Fagent-governance-reviewer.agent.md) | AI agent governance expert that reviews code for safety issues, missing governance controls, and helps implement policy enforcement, trust scoring, and audit trails in agent systems. | |
|
||||||
| [Ai Readiness Reporter](../agents/ai-readiness-reporter.agent.md)<br />[](https://aka.ms/awesome-copilot/install/agent?url=vscode%3Achat-agent%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fagents%2Fai-readiness-reporter.agent.md)<br />[](https://aka.ms/awesome-copilot/install/agent?url=vscode-insiders%3Achat-agent%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fagents%2Fai-readiness-reporter.agent.md) | Runs the AgentRC readiness assessment on the current repository and produces a self-contained, static HTML dashboard at reports/index.html. Explains every readiness pillar, the maturity level, and an actionable remediation plan, framed by AgentRC measure → generate → maintain loop. Use when asked to assess, audit, score, report on, or visualise the AI readiness of a repo. | |
|
| [Ai Readiness Reporter](../agents/ai-readiness-reporter.agent.md)<br />[](https://aka.ms/awesome-copilot/install/agent?url=vscode%3Achat-agent%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fagents%2Fai-readiness-reporter.agent.md)<br />[](https://aka.ms/awesome-copilot/install/agent?url=vscode-insiders%3Achat-agent%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fagents%2Fai-readiness-reporter.agent.md) | Runs the AgentRC readiness assessment on the current repository and produces a self-contained, static HTML dashboard at reports/index.html. Explains every readiness pillar, the maturity level, and an actionable remediation plan, framed by AgentRC measure → generate → maintain loop. Use when asked to assess, audit, score, report on, or visualise the AI readiness of a repo. | |
|
||||||
| [Ai Team Dev](../agents/ai-team-dev.agent.md)<br />[](https://aka.ms/awesome-copilot/install/agent?url=vscode%3Achat-agent%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fagents%2Fai-team-dev.agent.md)<br />[](https://aka.ms/awesome-copilot/install/agent?url=vscode-insiders%3Achat-agent%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fagents%2Fai-team-dev.agent.md) | AI development team agent (Nova, Sage, Milo). Use when: building features, writing application code, fixing bugs, implementing UI components, creating APIs, styling with CSS, writing database queries, or executing sprint plans. The team switches between frontend, backend, and design roles as needed. | |
|
| [Ai Team Dev](../agents/ai-team-dev.agent.md)<br />[](https://aka.ms/awesome-copilot/install/agent?url=vscode%3Achat-agent%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fagents%2Fai-team-dev.agent.md)<br />[](https://aka.ms/awesome-copilot/install/agent?url=vscode-insiders%3Achat-agent%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fagents%2Fai-team-dev.agent.md) | AI development team (Nova, Sage, Milo). Use when implementing features, fixing bugs, writing tests, improving user experience, or preparing a pull request across the project's actual stack. | |
|
||||||
| [Ai Team Producer](../agents/ai-team-producer.agent.md)<br />[](https://aka.ms/awesome-copilot/install/agent?url=vscode%3Achat-agent%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fagents%2Fai-team-producer.agent.md)<br />[](https://aka.ms/awesome-copilot/install/agent?url=vscode-insiders%3Achat-agent%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fagents%2Fai-team-producer.agent.md) | AI team producer agent (Remy). Use when: planning sprints, creating PROJECT_BRIEF.md, triaging bugs, merging PRs, coordinating between dev and QA teams, filing GitHub Issues, writing sprint plans, running brainstorms, or recovering project context. NEVER writes application code. | |
|
| [Ai Team Producer](../agents/ai-team-producer.agent.md)<br />[](https://aka.ms/awesome-copilot/install/agent?url=vscode%3Achat-agent%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fagents%2Fai-team-producer.agent.md)<br />[](https://aka.ms/awesome-copilot/install/agent?url=vscode-insiders%3Achat-agent%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fagents%2Fai-team-producer.agent.md) | AI team producer (Remy). Use when planning work, clarifying scope, coordinating Dev and optional QA, triaging issues, maintaining project context, or preparing and merging pull requests. Never writes application code. | |
|
||||||
| [Ai Team Qa](../agents/ai-team-qa.agent.md)<br />[](https://aka.ms/awesome-copilot/install/agent?url=vscode%3Achat-agent%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fagents%2Fai-team-qa.agent.md)<br />[](https://aka.ms/awesome-copilot/install/agent?url=vscode-insiders%3Achat-agent%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fagents%2Fai-team-qa.agent.md) | AI QA engineer agent (Ivy). Use when: testing features, running E2E tests, playtesting, filing bug reports, writing test automation, creating QA sign-off documents, or verifying bug fixes. Reports bugs as GitHub Issues. | |
|
| [Ai Team Qa](../agents/ai-team-qa.agent.md)<br />[](https://aka.ms/awesome-copilot/install/agent?url=vscode%3Achat-agent%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fagents%2Fai-team-qa.agent.md)<br />[](https://aka.ms/awesome-copilot/install/agent?url=vscode-insiders%3Achat-agent%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fagents%2Fai-team-qa.agent.md) | Optional AI QA engineer (Ivy). Use when testing behavior, running automated or exploratory checks, filing reproducible bugs, verifying fixes, or providing release confidence for changes that warrant dedicated QA. | |
|
||||||
| [Amplitude Experiment Implementation](../agents/amplitude-experiment-implementation.agent.md)<br />[](https://aka.ms/awesome-copilot/install/agent?url=vscode%3Achat-agent%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fagents%2Famplitude-experiment-implementation.agent.md)<br />[](https://aka.ms/awesome-copilot/install/agent?url=vscode-insiders%3Achat-agent%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fagents%2Famplitude-experiment-implementation.agent.md) | This custom agent uses Amplitude's MCP tools to deploy new experiments inside of Amplitude, enabling seamless variant testing capabilities and rollout of product features. | |
|
| [Amplitude Experiment Implementation](../agents/amplitude-experiment-implementation.agent.md)<br />[](https://aka.ms/awesome-copilot/install/agent?url=vscode%3Achat-agent%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fagents%2Famplitude-experiment-implementation.agent.md)<br />[](https://aka.ms/awesome-copilot/install/agent?url=vscode-insiders%3Achat-agent%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fagents%2Famplitude-experiment-implementation.agent.md) | This custom agent uses Amplitude's MCP tools to deploy new experiments inside of Amplitude, enabling seamless variant testing capabilities and rollout of product features. | |
|
||||||
| [API Architect](../agents/api-architect.agent.md)<br />[](https://aka.ms/awesome-copilot/install/agent?url=vscode%3Achat-agent%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fagents%2Fapi-architect.agent.md)<br />[](https://aka.ms/awesome-copilot/install/agent?url=vscode-insiders%3Achat-agent%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fagents%2Fapi-architect.agent.md) | Your role is that of an API architect. Help mentor the engineer by providing guidance, support, and working code. | |
|
| [API Architect](../agents/api-architect.agent.md)<br />[](https://aka.ms/awesome-copilot/install/agent?url=vscode%3Achat-agent%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fagents%2Fapi-architect.agent.md)<br />[](https://aka.ms/awesome-copilot/install/agent?url=vscode-insiders%3Achat-agent%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fagents%2Fapi-architect.agent.md) | Your role is that of an API architect. Help mentor the engineer by providing guidance, support, and working code. | |
|
||||||
| [Apify Integration Expert](../agents/apify-integration-expert.agent.md)<br />[](https://aka.ms/awesome-copilot/install/agent?url=vscode%3Achat-agent%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fagents%2Fapify-integration-expert.agent.md)<br />[](https://aka.ms/awesome-copilot/install/agent?url=vscode-insiders%3Achat-agent%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fagents%2Fapify-integration-expert.agent.md) | Expert agent for integrating Apify Actors into codebases. Handles Actor selection, workflow design, implementation across JavaScript/TypeScript and Python, testing, and production-ready deployment. | [apify](https://github.com/mcp/com.apify/apify-mcp-server)<br />[](https://aka.ms/awesome-copilot/install/mcp-vscode?name=apify&config=%7B%22url%22%3A%22https%3A%2F%2Fmcp.apify.com%22%2C%22headers%22%3A%7B%22Authorization%22%3A%22Bearer%20%24APIFY_TOKEN%22%2C%22Content-Type%22%3A%22application%2Fjson%22%7D%7D)<br />[](https://aka.ms/awesome-copilot/install/mcp-vscodeinsiders?name=apify&config=%7B%22url%22%3A%22https%3A%2F%2Fmcp.apify.com%22%2C%22headers%22%3A%7B%22Authorization%22%3A%22Bearer%20%24APIFY_TOKEN%22%2C%22Content-Type%22%3A%22application%2Fjson%22%7D%7D)<br />[](https://aka.ms/awesome-copilot/install/mcp-visualstudio/mcp-install?%7B%22url%22%3A%22https%3A%2F%2Fmcp.apify.com%22%2C%22headers%22%3A%7B%22Authorization%22%3A%22Bearer%20%24APIFY_TOKEN%22%2C%22Content-Type%22%3A%22application%2Fjson%22%7D%7D) |
|
| [Apify Integration Expert](../agents/apify-integration-expert.agent.md)<br />[](https://aka.ms/awesome-copilot/install/agent?url=vscode%3Achat-agent%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fagents%2Fapify-integration-expert.agent.md)<br />[](https://aka.ms/awesome-copilot/install/agent?url=vscode-insiders%3Achat-agent%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fagents%2Fapify-integration-expert.agent.md) | Expert agent for integrating Apify Actors into codebases. Handles Actor selection, workflow design, implementation across JavaScript/TypeScript and Python, testing, and production-ready deployment. | [apify](https://github.com/mcp/com.apify/apify-mcp-server)<br />[](https://aka.ms/awesome-copilot/install/mcp-vscode?name=apify&config=%7B%22url%22%3A%22https%3A%2F%2Fmcp.apify.com%22%2C%22headers%22%3A%7B%22Authorization%22%3A%22Bearer%20%24APIFY_TOKEN%22%2C%22Content-Type%22%3A%22application%2Fjson%22%7D%7D)<br />[](https://aka.ms/awesome-copilot/install/mcp-vscodeinsiders?name=apify&config=%7B%22url%22%3A%22https%3A%2F%2Fmcp.apify.com%22%2C%22headers%22%3A%7B%22Authorization%22%3A%22Bearer%20%24APIFY_TOKEN%22%2C%22Content-Type%22%3A%22application%2Fjson%22%7D%7D)<br />[](https://aka.ms/awesome-copilot/install/mcp-visualstudio/mcp-install?%7B%22url%22%3A%22https%3A%2F%2Fmcp.apify.com%22%2C%22headers%22%3A%7B%22Authorization%22%3A%22Bearer%20%24APIFY_TOKEN%22%2C%22Content-Type%22%3A%22application%2Fjson%22%7D%7D) |
|
||||||
|
|||||||
@@ -28,7 +28,7 @@ See [CONTRIBUTING.md](../CONTRIBUTING.md#adding-plugins) for guidelines on how t
|
|||||||
| Name | Description | Items | Tags |
|
| Name | Description | Items | Tags |
|
||||||
| ---- | ----------- | ----- | ---- |
|
| ---- | ----------- | ----- | ---- |
|
||||||
| [acreadiness-cockpit](../plugins/acreadiness-cockpit/README.md) | Drive Microsoft AgentRC from Copilot chat: assess AI readiness, generate Copilot instructions (flat or nested with applyTo globs for monorepos), and manage policies. Produces a self-contained static HTML dashboard at reports/index.html. | 4 items | agentrc, ai-readiness, copilot-instructions, readiness-report, monorepo, policy, dashboard |
|
| [acreadiness-cockpit](../plugins/acreadiness-cockpit/README.md) | Drive Microsoft AgentRC from Copilot chat: assess AI readiness, generate Copilot instructions (flat or nested with applyTo globs for monorepos), and manage policies. Produces a self-contained static HTML dashboard at reports/index.html. | 4 items | agentrc, ai-readiness, copilot-instructions, readiness-report, monorepo, policy, dashboard |
|
||||||
| [ai-team-orchestration](../plugins/ai-team-orchestration/README.md) | Bootstrap and run a multi-agent AI development team with named roles (Producer, Dev Team, QA). Sprint planning, brainstorm prompts with distinct agent voices, cross-chat context survival, and parallel team workflows. Based on a proven template that shipped a 30-game app in 5 days with zero human-written code. | 4 items | ai-team, multi-agent, sprint-planning, brainstorm, project-management, orchestration, developer-workflow |
|
| [ai-team-orchestration](../plugins/ai-team-orchestration/README.md) | Run a lightweight, role-separated AI development team with flexible tools, developer-selected models, proportionate planning, and optional QA. | 4 items | ai-team, multi-agent, sprint-planning, brainstorm, project-management, orchestration, developer-workflow |
|
||||||
| [arch](../plugins/arch/README.md) | Architecture and modernization toolkit: produce a cited architecture document for a locally-cloned repo, and generate a phased modernization plan that auto-runs Documentation mode when needed. | 1 items | architecture, modernization, documentation, migration, onboarding |
|
| [arch](../plugins/arch/README.md) | Architecture and modernization toolkit: produce a cited architecture document for a locally-cloned repo, and generate a phased modernization plan that auto-runs Documentation mode when needed. | 1 items | architecture, modernization, documentation, migration, onboarding |
|
||||||
| [arize-ax](../plugins/arize-ax/README.md) | Arize AX platform skills for LLM observability, evaluation, and optimization. Includes trace export, instrumentation, datasets, experiments, evaluators, AI provider integrations, annotations, prompt optimization, and deep linking to the Arize UI. | 9 items | arize, llm, observability, tracing, evaluation, instrumentation, datasets, experiments, prompt-optimization |
|
| [arize-ax](../plugins/arize-ax/README.md) | Arize AX platform skills for LLM observability, evaluation, and optimization. Includes trace export, instrumentation, datasets, experiments, evaluators, AI provider integrations, annotations, prompt optimization, and deep linking to the Arize UI. | 9 items | arize, llm, observability, tracing, evaluation, instrumentation, datasets, experiments, prompt-optimization |
|
||||||
| [automate-this](../plugins/automate-this/README.md) | Record your screen doing a manual process, drop the video on your Desktop, and let Copilot CLI analyze it frame-by-frame to build working automation scripts. Supports narrated recordings with audio transcription. | 1 items | automation, screen-recording, workflow, video-analysis, process-automation, scripting, productivity, copilot-cli |
|
| [automate-this](../plugins/automate-this/README.md) | Record your screen doing a manual process, drop the video on your Desktop, and let Copilot CLI analyze it frame-by-frame to build working automation scripts. Supports narrated recordings with audio transcription. | 1 items | automation, screen-recording, workflow, video-analysis, process-automation, scripting, productivity, copilot-cli |
|
||||||
|
|||||||
@@ -41,7 +41,7 @@ See [CONTRIBUTING.md](../CONTRIBUTING.md#adding-skills) for guidelines on how to
|
|||||||
| [agentic-eval](../skills/agentic-eval/SKILL.md)<br />`gh skills install github/awesome-copilot agentic-eval` | Patterns and techniques for evaluating and improving AI agent outputs. Use this skill when:<br />- Implementing self-critique and reflection loops<br />- Building evaluator-optimizer pipelines for quality-critical generation<br />- Creating test-driven code refinement workflows<br />- Designing rubric-based or LLM-as-judge evaluation systems<br />- Adding iterative improvement to agent outputs (code, reports, analysis)<br />- Measuring and improving agent response quality | None |
|
| [agentic-eval](../skills/agentic-eval/SKILL.md)<br />`gh skills install github/awesome-copilot agentic-eval` | Patterns and techniques for evaluating and improving AI agent outputs. Use this skill when:<br />- Implementing self-critique and reflection loops<br />- Building evaluator-optimizer pipelines for quality-critical generation<br />- Creating test-driven code refinement workflows<br />- Designing rubric-based or LLM-as-judge evaluation systems<br />- Adding iterative improvement to agent outputs (code, reports, analysis)<br />- Measuring and improving agent response quality | None |
|
||||||
| [ai-prompt-engineering-safety-review](../skills/ai-prompt-engineering-safety-review/SKILL.md)<br />`gh skills install github/awesome-copilot ai-prompt-engineering-safety-review` | Comprehensive AI prompt engineering safety review and improvement prompt. Analyzes prompts for safety, bias, security vulnerabilities, and effectiveness while providing detailed improvement recommendations with extensive frameworks, testing methodologies, and educational content. | None |
|
| [ai-prompt-engineering-safety-review](../skills/ai-prompt-engineering-safety-review/SKILL.md)<br />`gh skills install github/awesome-copilot ai-prompt-engineering-safety-review` | Comprehensive AI prompt engineering safety review and improvement prompt. Analyzes prompts for safety, bias, security vulnerabilities, and effectiveness while providing detailed improvement recommendations with extensive frameworks, testing methodologies, and educational content. | None |
|
||||||
| [ai-ready](../skills/ai-ready/SKILL.md)<br />`gh skills install github/awesome-copilot ai-ready` | Make any repo AI-ready — analyzes your codebase and generates AGENTS.md, copilot-instructions.md, CI workflows, issue templates, and more. Mines your PR review patterns and creates files customized to your stack. USE THIS SKILL when the user asks to "make this repo ai-ready", "set up AI config", or "prepare this repo for AI contributions". | None |
|
| [ai-ready](../skills/ai-ready/SKILL.md)<br />`gh skills install github/awesome-copilot ai-ready` | Make any repo AI-ready — analyzes your codebase and generates AGENTS.md, copilot-instructions.md, CI workflows, issue templates, and more. Mines your PR review patterns and creates files customized to your stack. USE THIS SKILL when the user asks to "make this repo ai-ready", "set up AI config", or "prepare this repo for AI contributions". | None |
|
||||||
| [ai-team-orchestration](../skills/ai-team-orchestration/SKILL.md)<br />`gh skills install github/awesome-copilot ai-team-orchestration` | 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. | `references/anti-patterns.md`<br />`references/brainstorm-format.md`<br />`references/project-brief-template.md`<br />`references/sprint-plan-template.md` |
|
| [ai-team-orchestration](../skills/ai-team-orchestration/SKILL.md)<br />`gh skills install github/awesome-copilot ai-team-orchestration` | Bootstrap and run a lightweight multi-agent development team. Use when starting or adopting a project, planning work, coordinating implementation and optional QA, brainstorming with distinct perspectives, or preserving context across sessions. | `references/anti-patterns.md`<br />`references/brainstorm-format.md`<br />`references/project-brief-template.md`<br />`references/sprint-plan-template.md` |
|
||||||
| [anti-ui-slop](../skills/anti-ui-slop/SKILL.md)<br />`gh skills install github/awesome-copilot anti-ui-slop` | Stop Codex, GitHub Copilot, Claude Code, and Cursor from shipping generic UI. Use UIZZE’s public catalogue of 800,000+ real web and iOS screens to extract product-specific design decisions and enforce a hard finish gate for web and iOS interfaces. | None |
|
| [anti-ui-slop](../skills/anti-ui-slop/SKILL.md)<br />`gh skills install github/awesome-copilot anti-ui-slop` | Stop Codex, GitHub Copilot, Claude Code, and Cursor from shipping generic UI. Use UIZZE’s public catalogue of 800,000+ real web and iOS screens to extract product-specific design decisions and enforce a hard finish gate for web and iOS interfaces. | None |
|
||||||
| [appinsights-instrumentation](../skills/appinsights-instrumentation/SKILL.md)<br />`gh skills install github/awesome-copilot appinsights-instrumentation` | Instrument a webapp to send useful telemetry data to Azure App Insights | `LICENSE.txt`<br />`examples`<br />`references/ASPNETCORE.md`<br />`references/AUTO.md`<br />`references/NODEJS.md`<br />`references/PYTHON.md`<br />`scripts/appinsights.ps1` |
|
| [appinsights-instrumentation](../skills/appinsights-instrumentation/SKILL.md)<br />`gh skills install github/awesome-copilot appinsights-instrumentation` | Instrument a webapp to send useful telemetry data to Azure App Insights | `LICENSE.txt`<br />`examples`<br />`references/ASPNETCORE.md`<br />`references/AUTO.md`<br />`references/NODEJS.md`<br />`references/PYTHON.md`<br />`scripts/appinsights.ps1` |
|
||||||
| [apple-appstore-reviewer](../skills/apple-appstore-reviewer/SKILL.md)<br />`gh skills install github/awesome-copilot apple-appstore-reviewer` | Serves as a reviewer of the codebase with instructions on looking for Apple App Store optimizations or rejection reasons. | None |
|
| [apple-appstore-reviewer](../skills/apple-appstore-reviewer/SKILL.md)<br />`gh skills install github/awesome-copilot apple-appstore-reviewer` | Serves as a reviewer of the codebase with instructions on looking for Apple App Store optimizations or rejection reasons. | None |
|
||||||
|
|||||||
@@ -1,7 +1,7 @@
|
|||||||
{
|
{
|
||||||
"name": "ai-team-orchestration",
|
"name": "ai-team-orchestration",
|
||||||
"description": "Bootstrap and run a multi-agent AI development team with named roles (Producer, Dev Team, QA). Sprint planning, brainstorm prompts with distinct agent voices, cross-chat context survival, and parallel team workflows. Based on a proven template that shipped a 30-game app in 5 days with zero human-written code.",
|
"description": "Run a lightweight, role-separated AI development team with flexible tools, developer-selected models, proportionate planning, and optional QA.",
|
||||||
"version": "1.0.0",
|
"version": "2.0.0",
|
||||||
"keywords": [
|
"keywords": [
|
||||||
"ai-team",
|
"ai-team",
|
||||||
"multi-agent",
|
"multi-agent",
|
||||||
|
|||||||
@@ -1,63 +1,69 @@
|
|||||||
# AI Team Orchestration
|
# AI Team Orchestration
|
||||||
|
|
||||||
Bootstrap and run a multi-agent AI development team with named roles (Producer, Dev Team, QA). Plan sprints, run brainstorms with distinct agent voices, coordinate parallel dev/QA workflows, and survive context overflows with structured handoff templates.
|
Run a lightweight, role-separated AI development team with flexible tools, developer-selected models, proportionate planning, and optional QA.
|
||||||
|
|
||||||
## What's Included
|
## What's Included
|
||||||
|
|
||||||
### Agents
|
### Agents
|
||||||
|
|
||||||
| Agent | Mention | Role | Tool Access |
|
| Agent | Mention | Role |
|
||||||
|-------|---------|------|-------------|
|
|---|---|---|
|
||||||
| **Producer** (Remy) | `@ai-team-producer` | Sprint planning, coordination, PR merging | Read-only (no code editing) |
|
| **Producer** (Remy) | `@ai-team-producer` | Scope, planning, coordination, triage, and merge |
|
||||||
| **Dev Team** (Nova, Sage, Milo) | `@ai-team-dev` | Frontend, backend, and visual implementation | Full coding tools |
|
| **Dev Team** (Nova, Sage, Milo) | `@ai-team-dev` | Stack-adaptive implementation, tests, self-review, and pull requests |
|
||||||
| **QA** (Ivy) | `@ai-team-qa` | Testing, bug filing, sign-off | Read + test (no source editing) |
|
| **QA** (Ivy) | `@ai-team-qa` | Optional independent behavioral testing and fix verification |
|
||||||
|
|
||||||
|
The agents intentionally omit `tools` and `model` frontmatter. They inherit the developer's enabled built-in, MCP, and extension tools and use the developer-selected model. Role boundaries remain in the instructions and normal permission and approval controls.
|
||||||
|
|
||||||
### Skill
|
### Skill
|
||||||
|
|
||||||
`/ai-team-orchestration` provides templates for:
|
`/ai-team-orchestration` provides:
|
||||||
- **PROJECT_BRIEF.md** — 14-section single source of truth across chats
|
|
||||||
- **Brainstorm format** — multi-agent debate with distinct voices
|
- a concise project brief template;
|
||||||
- **Sprint plans** — prioritized tasks, progress trackers, handoff docs
|
- a proportional work-plan template;
|
||||||
- **Anti-patterns** — 19 documented pitfalls from real multi-agent projects
|
- brainstorm guidance with distinct perspectives;
|
||||||
|
- practical anti-patterns for multi-agent work.
|
||||||
|
|
||||||
|
## Default Workflow
|
||||||
|
|
||||||
|
```text
|
||||||
|
Plan -> Implement -> Test -> optional review or QA -> Merge -> update project state
|
||||||
|
```
|
||||||
|
|
||||||
|
Use the lightest process that fits the work. Small changes can proceed directly; substantial or risky changes benefit from a short plan, independent review, or dedicated QA.
|
||||||
|
|
||||||
## Quick Start
|
## Quick Start
|
||||||
|
|
||||||
### 1. Bootstrap a project
|
### Plan
|
||||||
|
|
||||||
```
|
```text
|
||||||
@ai-team-producer I want to build [describe your project].
|
@ai-team-producer Help me define the next useful outcome for this project.
|
||||||
Use /ai-team-orchestration to bootstrap this project.
|
Use /ai-team-orchestration and keep planning proportional to the work.
|
||||||
Start with a brainstorm, then create PROJECT_BRIEF.md with ALL sections (1-14).
|
|
||||||
```
|
```
|
||||||
|
|
||||||
### 2. Plan a sprint
|
### Implement
|
||||||
|
|
||||||
```
|
```text
|
||||||
@ai-team-producer Create Sprint 1 plan. Scope: [what to build].
|
@ai-team-dev Read the repository instructions and active plan or issue.
|
||||||
Run a team consilium to validate the plan.
|
Implement the requested outcome, run relevant checks, self-review the diff,
|
||||||
|
and prepare the pull request. Do not merge.
|
||||||
```
|
```
|
||||||
|
|
||||||
### 3. Execute (separate VS Code window)
|
### Optional QA
|
||||||
|
|
||||||
```
|
```text
|
||||||
@ai-team-dev Read PROJECT_BRIEF.md, then docs/sprint-1/plan.md. Execute Sprint 1.
|
@ai-team-qa Test the pull request against its acceptance criteria.
|
||||||
|
Focus on important behavior and regressions. Report Ready, Ready with minor
|
||||||
|
follow-ups, or Blocked with reproducible findings.
|
||||||
```
|
```
|
||||||
|
|
||||||
### 4. Test (another VS Code window)
|
## Principles
|
||||||
|
|
||||||
```
|
- Producer coordinates but never implements application code.
|
||||||
@ai-team-qa Sprint 1 is merged to main. Do full playthrough.
|
- Dev implements and verifies but never merges or claims independent approval.
|
||||||
File bugs as GitHub Issues. Write docs/qa/sprint-1-signoff.md.
|
- QA is optional and independently verifies behavior without fixing application source.
|
||||||
```
|
- Repository contribution policy and platform protections define Git and merge behavior.
|
||||||
|
- Important context and bugs live in durable project files or issue trackers, not only chat.
|
||||||
## How It Works
|
|
||||||
|
|
||||||
The human acts as the message bus between parallel chats. Each team works in a separate VS Code window with its own repo clone:
|
|
||||||
|
|
||||||
- **@ai-team-producer** — cannot edit code (enforced by tool restrictions)
|
|
||||||
- **@ai-team-qa** — cannot edit source files, only reads/tests/files bugs
|
|
||||||
- **@ai-team-dev** — full tools, builds as Nova (frontend), Sage (backend), Milo (design)
|
|
||||||
|
|
||||||
## Origin
|
## Origin
|
||||||
|
|
||||||
Codifies the workflow that shipped [Arcade After Dark](https://github.com/denis-a-evdokimov/guess-and-get) — a 30-game birthday gift app built entirely by 7 AI agents in 5 days.
|
The plugin grew from [Arcade After Dark](https://github.com/denis-a-evdokimov/guess-and-get), a multi-agent project built with distinct planning, implementation, design, and QA perspectives.
|
||||||
|
|||||||
@@ -1,148 +1,92 @@
|
|||||||
---
|
---
|
||||||
name: ai-team-orchestration
|
name: ai-team-orchestration
|
||||||
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.'
|
description: 'Bootstrap and run a lightweight multi-agent development team. Use when starting or adopting a project, planning work, coordinating implementation and optional QA, brainstorming with distinct perspectives, or preserving context across sessions.'
|
||||||
---
|
---
|
||||||
|
|
||||||
# AI Team Orchestration
|
# AI Team Orchestration
|
||||||
|
|
||||||
## When to Use
|
Use three stable agents:
|
||||||
- Starting a new project that needs planning, development, testing, and deployment
|
|
||||||
- Setting up parallel AI agent teams (dev, QA, DevOps)
|
|
||||||
- Writing brainstorm prompts that produce real debate (not generic output)
|
|
||||||
- Creating sprint plans with cross-chat context survival
|
|
||||||
- Recovering from context overflow mid-sprint
|
|
||||||
|
|
||||||
## Team Roles
|
| Agent | Purpose |
|
||||||
|
|---|---|
|
||||||
|
| `@ai-team-producer` | Clarify scope, plan proportionately, coordinate, and merge |
|
||||||
|
| `@ai-team-dev` | Implement, test, self-review, and prepare the pull request |
|
||||||
|
| `@ai-team-qa` | Independently test behavior when dedicated QA is useful |
|
||||||
|
|
||||||
| Agent | Name | Role | Focus |
|
Nova, Sage, and Milo are perspectives inside the Dev agent, not mandatory project layers.
|
||||||
|-------|------|------|-------|
|
|
||||||
| Producer | **Remy** | Sprint planning, coordination, merging PRs | Scope control, handoffs, issue triage |
|
|
||||||
| Product Designer | **Kira** | UX, mechanics, user experience | Fun factor, user flows, feature design |
|
|
||||||
| Visual/Art Director | **Milo** | CSS, animations, visual identity | Design system, polish, accessibility |
|
|
||||||
| Frontend Engineer | **Nova** | UI framework, state management, components | React/Vue/Svelte, client-side logic |
|
|
||||||
| Backend Engineer | **Sage** | API, database, auth, security | Server-side logic, infrastructure |
|
|
||||||
| DevOps Engineer | **Dash** | CI/CD, cloud deployment, pipelines | GitHub Actions, Azure/AWS/GCP |
|
|
||||||
| QA Engineer | **Ivy** | E2E tests, automation, playtesting | Playwright/Cypress, bug filing, sign-off |
|
|
||||||
|
|
||||||
Customize names and roles for your project. Not every project needs all roles.
|
## Default Workflow
|
||||||
|
|
||||||
## Chat Architecture
|
**Plan -> Implement -> Test -> optional review or QA -> Merge -> update project state**
|
||||||
|
|
||||||
The human (CEO) is the message bus between parallel chats:
|
Keep the workflow proportional:
|
||||||
|
|
||||||
```
|
- Skip formal planning for small, obvious changes.
|
||||||
┌────────────────────────────────────────┐
|
- Use a short plan for multi-step or cross-cutting work.
|
||||||
│ @ai-team-producer — Plans, merges │
|
- Add independent review or QA when risk, uncertainty, or repository policy justifies it.
|
||||||
│ NEVER writes code │
|
- Let branch protection, required checks, permissions, and merge queues enforce repository merge policy.
|
||||||
└────────────────┬───────────────────────┘
|
|
||||||
│ Human carries messages
|
|
||||||
┌──────────┼──────────┐
|
|
||||||
▼ ▼ ▼
|
|
||||||
┌──────────┐ ┌────────┐ ┌────────┐
|
|
||||||
│@ai-team │ │@ai-team│ │DevOps │
|
|
||||||
│-dev │ │-qa │ │(on │
|
|
||||||
│ │ │ │ │demand) │
|
|
||||||
│ Nova │ │ Ivy │ │ │
|
|
||||||
│ Sage │ │ │ │ │
|
|
||||||
│ Milo │ │ │ │ │
|
|
||||||
│ │ │feature/│ │feature/│
|
|
||||||
│ feature/ │ │qa-N │ │devops-N│
|
|
||||||
│ sprint-N │ └────────┘ └────────┘
|
|
||||||
└──────────┘
|
|
||||||
```
|
|
||||||
|
|
||||||
Each team works in a **separate VS Code window** with its own clone:
|
## Start or Adopt a Project
|
||||||
```bash
|
|
||||||
git clone <repo> project-dev # Dev team
|
|
||||||
git clone <repo> project-qa # QA
|
|
||||||
git clone <repo> project-devops # DevOps (only when needed)
|
|
||||||
```
|
|
||||||
|
|
||||||
## Project Bootstrap
|
1. Read existing repository instructions and documentation.
|
||||||
|
2. Discover the actual stack, architecture, commands, deployment model, and risks.
|
||||||
|
3. Create or update `PROJECT_BRIEF.md` only when durable cross-session context is useful. Start from the [project brief template](./references/project-brief-template.md) and omit irrelevant sections.
|
||||||
|
4. For substantial work, create a concise plan from the [sprint plan template](./references/sprint-plan-template.md).
|
||||||
|
5. Use a separate branch or clone when parallel sessions could conflict, following the repository's own Git policy.
|
||||||
|
|
||||||
### 1. Create PROJECT_BRIEF.md
|
## Execute
|
||||||
|
|
||||||
The single source of truth across all chats. See the [project brief template](./references/project-brief-template.md).
|
### Producer
|
||||||
|
|
||||||
**Required sections (do not abbreviate):**
|
- Define the outcome, constraints, acceptance criteria, and explicit exclusions.
|
||||||
1. Project Overview
|
- Choose review and QA based on risk rather than ceremony.
|
||||||
2. Concept / Product Description
|
- Keep durable project state concise and current.
|
||||||
3. Tech Stack
|
|
||||||
4. Architecture (ASCII diagram)
|
|
||||||
5. Key Files Map
|
|
||||||
6. Team Roles
|
|
||||||
7. Sprint Status (updated every sprint)
|
|
||||||
8. Current State (rewritten every sprint)
|
|
||||||
9. Security Rules
|
|
||||||
10. How to Run Locally
|
|
||||||
11. How to Deploy
|
|
||||||
12. **Cross-Chat Handoff Protocol** — how context survives between chats
|
|
||||||
13. **Bug & Fix Tracking** — GitHub Issues as single source of truth
|
|
||||||
14. **Multi-Repo Setup** — separate clones, branch strategy, merge rules
|
|
||||||
|
|
||||||
### 2. Run a Brainstorm
|
### Dev
|
||||||
|
|
||||||
See 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.
|
- Follow repository conventions and implement the smallest complete solution.
|
||||||
|
- Run relevant checks and inspect the final diff.
|
||||||
|
- Open or update the pull request with summary, verification, and limitations.
|
||||||
|
|
||||||
### 3. Create Sprint Plans
|
### QA
|
||||||
|
|
||||||
See the [sprint plan template](./references/sprint-plan-template.md). Every sprint gets:
|
- Use only when dedicated behavioral verification adds value.
|
||||||
- `docs/sprint-N/plan.md` — prioritized tasks, success criteria
|
- Test the requested change and important regressions.
|
||||||
- `docs/sprint-N/progress.md` — live tracker, enables recovery
|
- Report reproducible findings and verify fixes.
|
||||||
- `docs/sprint-N/done.md` — handoff doc written at sprint end
|
|
||||||
|
|
||||||
### 4. Execute Sprints
|
## Brainstorms
|
||||||
|
|
||||||
```
|
Use the [brainstorm format](./references/brainstorm-format.md) for product or architecture decisions that benefit from competing perspectives. For ordinary implementation choices, let Dev decide using repository conventions.
|
||||||
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.
|
|
||||||
```
|
|
||||||
|
|
||||||
### 5. QA Sign-off
|
|
||||||
|
|
||||||
After dev merges, QA does a full playthrough:
|
|
||||||
```
|
|
||||||
Read PROJECT_BRIEF.md. You are Ivy (QA).
|
|
||||||
Sprint N is merged to main. Do full playthrough.
|
|
||||||
File bugs as GitHub Issues. Write docs/qa/sprint-N-signoff.md.
|
|
||||||
```
|
|
||||||
|
|
||||||
## Context Recovery
|
## Context Recovery
|
||||||
|
|
||||||
When a chat gets long (>100 messages), save state and start fresh:
|
Before ending a long or interrupted session:
|
||||||
|
|
||||||
**Before closing:**
|
1. Update the active plan or progress note if one exists.
|
||||||
1. Update `docs/sprint-N/progress.md` with current status
|
2. Record material decisions, blockers, and the next action in repository context.
|
||||||
2. Update `PROJECT_BRIEF.md` sections 7+8
|
3. Use a cold-start prompt such as:
|
||||||
3. Write `docs/sprint-N/done.md`
|
|
||||||
|
|
||||||
**Cold start prompt:**
|
```text
|
||||||
```
|
Read the repository instructions, then read whichever sources exist for this
|
||||||
Read PROJECT_BRIEF.md and docs/sprint-N/progress.md.
|
work: the active issue or request, PROJECT_BRIEF.md, and the active plan or
|
||||||
Continue from where it left off.
|
progress note.
|
||||||
|
Continue from the recorded next action.
|
||||||
```
|
```
|
||||||
|
|
||||||
## Anti-Patterns
|
## Tool and Model Inheritance
|
||||||
|
|
||||||
See [anti-patterns reference](./references/anti-patterns.md) for the full list. Top 5:
|
The bundled agents intentionally omit `tools` and `model` frontmatter:
|
||||||
|
|
||||||
| Don't | Do Instead |
|
- available built-in, MCP, and extension tools remain usable;
|
||||||
|-------|------------|
|
- developers keep control of model selection;
|
||||||
| Rebase feature branches | Merge (rebase loses commits) |
|
- role boundaries are defined by instructions and normal trust, permission, authentication, and approval controls.
|
||||||
| Producer writes code | Producer only plans, merges, files issues |
|
|
||||||
| Batch "fix everything" commits | One commit per fix with issue reference |
|
|
||||||
| Vague brainstorm prompts | Name each agent with distinct perspective |
|
|
||||||
| Keep bugs only in chat | File GitHub Issues (chat context dies) |
|
|
||||||
|
|
||||||
## Tips for Better Results
|
If the environment exposes too many tools, deselect irrelevant tools or MCP servers, or use VS Code virtual-tool management. Do not add a machine-specific plugin allowlist.
|
||||||
|
|
||||||
- **"Take your time, do it right"** in prompts produces better output than rushing
|
## Principles
|
||||||
- **Test before merge** — you playtest, file issues, dev fixes, then merge
|
|
||||||
- **Run team consiliums** before major sprints — each agent reviews the plan from their perspective
|
- Prefer working software and clear handoffs over process artifacts.
|
||||||
- **Save lessons to memory** after every milestone
|
- Follow repository policy instead of embedding universal Git commands.
|
||||||
|
- Preserve unknown work and ask before destructive or privileged actions.
|
||||||
|
- Keep bugs and important decisions in durable project systems, not only chat.
|
||||||
|
- See [anti-patterns](./references/anti-patterns.md) for concise lessons.
|
||||||
|
|||||||
@@ -1,48 +1,13 @@
|
|||||||
# Anti-Patterns
|
# Anti-Patterns
|
||||||
|
|
||||||
Lessons learned from real multi-agent projects. Each anti-pattern was encountered at least once and caused real problems.
|
| Avoid | Prefer | Why |
|
||||||
|
|---|---|---|
|
||||||
## Git & Branching
|
| One agent owns planning, implementation, testing, and approval | Keep Producer, Dev, and optional QA responsibilities distinct | Independent perspectives reduce blind spots without requiring ceremony for every change. |
|
||||||
|
| Hardcoded tool or model allowlists | Inherit the developer's enabled tools and selected model | Extensions and MCP tools remain available without plugin updates. |
|
||||||
| Don't | Do Instead | Why |
|
| A mandatory process for every change | Scale planning, review, and QA to risk | Small changes stay fast; high-impact changes receive more scrutiny. |
|
||||||
|-------|------------|-----|
|
| Universal Git command recipes | Follow repository contribution and branch policy | Projects use different remotes, protections, and merge strategies. |
|
||||||
| Rebase feature branches | Regular merge | Rebase rewrites history and loses commits. When multiple chats contribute to a branch, rebase causes cascading regressions. |
|
| Rewriting shared history or discarding unknown work | Preserve work and coordinate destructive actions | Parallel sessions and contributors may depend on existing state. |
|
||||||
| Squash merge PRs | Regular merge | Squash hides individual commits, making it impossible to revert a single fix. |
|
| Large plans that duplicate project documentation | Record only outcomes, constraints, decisions, and next actions | Concise context is easier to maintain and recover. |
|
||||||
| Use worktrees on shared branches | Separate clones | Worktrees share the git index. Parallel teams stepping on each other's staging area causes confusion. |
|
| Bugs and decisions kept only in chat | Use the repository's issue tracker and durable context | Future sessions can discover them. |
|
||||||
| Push directly to main | Feature branch → PR → merge | Direct pushes bypass review and can't be reverted cleanly. |
|
| QA fixes application source | QA reports behavior; Dev implements fixes | Separation preserves independent verification. |
|
||||||
| Force push (`--force`) | Fix forward or revert | Force push destroys remote history that other teams may have pulled. |
|
| Treating every automated suggestion as a requirement | Assess relevance, confidence, scope, and practical risk | Review should improve the product, not expand scope without limit. |
|
||||||
|
|
||||||
## 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. |
|
|
||||||
|
|||||||
@@ -14,16 +14,16 @@ This is a creative session — no idea is too wild in Phase 1.
|
|||||||
- Thinks about: user delight, accessibility, "would this be fun?"
|
- Thinks about: user delight, accessibility, "would this be fun?"
|
||||||
- Tendency: pushes for features that spark joy, pushes back on anything that feels like homework
|
- Tendency: pushes for features that spark joy, pushes back on anything that feels like homework
|
||||||
|
|
||||||
### Milo (Art/Visual Director)
|
### Milo (Experience/Design Perspective)
|
||||||
- Thinks about: visual identity, cohesion, "does this look and feel right?"
|
- Thinks about: accessibility, presentation, content, cohesion, "does this feel right?"
|
||||||
- Tendency: wants everything beautiful, sometimes at odds with engineering feasibility
|
- Tendency: advocates for user experience, sometimes at odds with engineering feasibility
|
||||||
|
|
||||||
### Nova (Frontend Engineer)
|
### Nova (Client/Interaction Perspective)
|
||||||
- Thinks about: component architecture, state management, "can we actually build this?"
|
- Thinks about: user-facing behavior, interaction, state, "can we actually build this?"
|
||||||
- Tendency: pragmatic, flags scope risks, suggests simpler alternatives
|
- Tendency: pragmatic, flags scope risks, suggests simpler alternatives
|
||||||
|
|
||||||
### Sage (Backend Engineer)
|
### Sage (Core/Service Perspective)
|
||||||
- Thinks about: data model, API design, security, "where do secrets live?"
|
- Thinks about: domain logic, data, services, integrations, security, "where do risks live?"
|
||||||
- Tendency: security-first, sometimes over-engineers, good at spotting edge cases
|
- Tendency: security-first, sometimes over-engineers, good at spotting edge cases
|
||||||
|
|
||||||
### Remy (Producer)
|
### Remy (Producer)
|
||||||
@@ -49,12 +49,7 @@ Phase 3 — Final Pitches:
|
|||||||
Each concept includes: name, description, pros, cons, estimated effort.
|
Each concept includes: name, description, pros, cons, estimated effort.
|
||||||
Team vote with brief justification from each voter.
|
Team vote with brief justification from each voter.
|
||||||
|
|
||||||
Output all phases as separate files:
|
Write the result to one concise design note unless the project needs separate artifacts.
|
||||||
- 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
|
## Tips
|
||||||
@@ -62,12 +57,12 @@ Output all phases as separate files:
|
|||||||
- **Name each agent** — "you are the full team" produces bland consensus
|
- **Name each agent** — "you are the full team" produces bland consensus
|
||||||
- **Define tendencies** — gives the LLM permission to disagree
|
- **Define tendencies** — gives the LLM permission to disagree
|
||||||
- **Require disagreements** — "at least 2 genuine disagreements" prevents groupthink
|
- **Require disagreements** — "at least 2 genuine disagreements" prevents groupthink
|
||||||
- **Separate files** — forces structured output, makes it reviewable
|
- **Keep the output proportional** — one note is usually enough
|
||||||
- **Customize personas** — adjust for your domain (e.g., replace Kira with a Data Scientist for ML projects)
|
- **Customize personas** — adjust for your domain (e.g., replace Kira with a Data Scientist for ML projects)
|
||||||
|
|
||||||
## Mini-Brainstorm (Quick Version)
|
## Mini-Brainstorm (Quick Version)
|
||||||
|
|
||||||
For smaller decisions:
|
For smaller decisions (e.g., "how should we implement the scoreboard?"):
|
||||||
|
|
||||||
```
|
```
|
||||||
Run a team brainstorm about [TOPIC].
|
Run a team brainstorm about [TOPIC].
|
||||||
|
|||||||
@@ -1,147 +1,70 @@
|
|||||||
# PROJECT_BRIEF.md Template
|
# 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.
|
Use this only when the project benefits from durable context across sessions. Keep it concise and omit irrelevant sections.
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
```markdown
|
```markdown
|
||||||
# PROJECT_BRIEF.md — [Project Name]
|
# PROJECT_BRIEF.md - [Project Name]
|
||||||
|
|
||||||
> Last updated: [date] | Sprint [N] | Status: [In Progress / Complete]
|
> Last updated: [date]
|
||||||
|
|
||||||
## 1. Project Overview
|
## 1. Goal and Users
|
||||||
|
|
||||||
[3-4 sentences describing what the project is, who it's for, and the core goal.]
|
[What the project is, who it serves, and the outcome it should create.]
|
||||||
|
|
||||||
## 2. Concept / Product Description
|
## 2. Current Scope
|
||||||
|
|
||||||
[Detailed description of the product — user flows, key features, narrative if applicable.]
|
**In scope**
|
||||||
|
- [outcome]
|
||||||
|
|
||||||
## 3. Tech Stack
|
**Out of scope**
|
||||||
|
- [explicit exclusion]
|
||||||
|
|
||||||
- **Frontend:** [framework, language, key libraries]
|
## 3. Stack and Architecture
|
||||||
- **Backend:** [runtime, framework, database]
|
|
||||||
- **Hosting:** [platform, CDN, storage]
|
|
||||||
- **Testing:** [test framework, E2E tool]
|
|
||||||
- **CI/CD:** [pipeline tool]
|
|
||||||
|
|
||||||
## 4. Architecture
|
- Runtime/language: [value]
|
||||||
|
- Frameworks/libraries: [value]
|
||||||
|
- Data/services: [value]
|
||||||
|
- Deployment: [value or not applicable]
|
||||||
|
- Tests/checks: [verified commands]
|
||||||
|
|
||||||
```
|
[Short architecture description or diagram when useful.]
|
||||||
┌─────────────────────────────────────────┐
|
|
||||||
│ Frontend │
|
## 4. Key Files
|
||||||
│ [Main Component] → [Sub Components] │
|
|
||||||
└──────────────┬──────────────────────────┘
|
| Area | Path | Purpose |
|
||||||
│ HTTPS
|
|---|---|---|
|
||||||
┌──────────────▼──────────────────────────┐
|
| [area] | `[path]` | [purpose] |
|
||||||
│ Backend API │
|
|
||||||
│ [Endpoints and their purpose] │
|
## 5. How to Work
|
||||||
└──────────────┬──────────────────────────┘
|
|
||||||
│
|
- Setup: [verified command or link]
|
||||||
┌──────────────▼──────────────────────────┐
|
- Run: [verified command or link]
|
||||||
│ Storage / Database │
|
- Test: [verified commands]
|
||||||
│ [Tables, collections, env vars] │
|
- Deploy: [verified process or not applicable]
|
||||||
└─────────────────────────────────────────┘
|
- Repository rules: [links to contribution/security instructions]
|
||||||
```
|
|
||||||
|
## 6. Safety and Constraints
|
||||||
## 5. Key Files Map
|
|
||||||
|
- [secrets/privacy/data rules]
|
||||||
| Area | Path | Contents |
|
- [compatibility or reliability invariant]
|
||||||
|------|------|----------|
|
- [operational constraint]
|
||||||
| Entry point | `src/main.tsx` | App bootstrap |
|
|
||||||
| API | `api/src/` | Server-side logic |
|
## 7. Current State
|
||||||
| Config | `api/src/config/` | Server-only configuration |
|
|
||||||
| Tests | `tests/` | E2E and API tests |
|
**Working**
|
||||||
| Sprint docs | `docs/sprint-N/` | Plans, progress, done |
|
- [item]
|
||||||
|
|
||||||
## 6. Team Roles
|
**Known issues**
|
||||||
|
- [issue/link]
|
||||||
| Agent | Name | Role |
|
|
||||||
|-------|------|------|
|
**Next**
|
||||||
| Producer | Remy | Sprint plans, coordination, merging |
|
- [next outcome]
|
||||||
| Frontend | Nova | UI components, state, client logic |
|
|
||||||
| Backend | Sage | API, auth, database, security |
|
## 8. Team and Handoff
|
||||||
| Art/CSS | Milo | Visual design, animations, polish |
|
|
||||||
| QA | Ivy | Testing, bug filing, sign-off |
|
- Producer: scope, coordination, and merge
|
||||||
| Product | Kira | UX design, mechanics, feature specs |
|
- Dev: implementation and verification
|
||||||
| DevOps | Dash | CI/CD, deployment, infrastructure |
|
- QA: optional independent behavioral verification
|
||||||
|
|
||||||
## 7. Sprint Status
|
Record material decisions, blockers, and the next action here or in the active plan. Use GitHub Issues or the repository's tracker for bugs and follow-up work.
|
||||||
|
|
||||||
| 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).
|
|
||||||
```
|
```
|
||||||
|
|||||||
@@ -1,140 +1,75 @@
|
|||||||
# Sprint Plan Template
|
# Work Plan Template
|
||||||
|
|
||||||
## Plan File
|
Use this for substantial work. Small, clear changes can proceed directly from the issue or request.
|
||||||
|
|
||||||
Save as `docs/sprint-N/plan.md`:
|
|
||||||
|
|
||||||
```markdown
|
```markdown
|
||||||
# Sprint N — [Name]
|
# [Work Item] - Plan
|
||||||
|
|
||||||
> Sprint Goal: [one sentence describing the deliverable]
|
## Goal
|
||||||
> Branch: feature/sprint-N
|
|
||||||
> Estimated effort: [time estimate]
|
|
||||||
|
|
||||||
## Prioritized Task List
|
[One observable outcome.]
|
||||||
|
|
||||||
| # | Task | Owner | Est | Description |
|
## Context
|
||||||
|---|------|-------|-----|-------------|
|
|
||||||
| 1 | [task] | Nova | 1h | [what to build] |
|
|
||||||
| 2 | [task] | Sage | 2h | [what to build] |
|
|
||||||
| 3 | [task] | Milo | 1h | [what to style] |
|
|
||||||
|
|
||||||
## Work Schedule
|
- Relevant issue/request: [link or summary]
|
||||||
|
- Repository instructions: [links]
|
||||||
|
- Important constraints: [list]
|
||||||
|
|
||||||
### Phase 1: [Name] (tasks 1-3)
|
## In Scope
|
||||||
- Build [component]
|
|
||||||
- Checkpoint commit after phase
|
|
||||||
|
|
||||||
### Phase 2: [Name] (tasks 4-6)
|
- [deliverable]
|
||||||
- Build [component]
|
|
||||||
- Checkpoint commit after phase
|
|
||||||
|
|
||||||
### Phase 3: Polish & Integration
|
## Out of Scope
|
||||||
- Integration testing
|
|
||||||
- Bug fixes
|
|
||||||
- Final commit
|
|
||||||
|
|
||||||
## Success Criteria
|
- [explicit exclusion]
|
||||||
|
|
||||||
- [ ] [Testable criterion 1]
|
## Tasks
|
||||||
- [ ] [Testable criterion 2]
|
|
||||||
- [ ] [Testable criterion 3]
|
|
||||||
- [ ] All tests pass
|
|
||||||
- [ ] No console errors
|
|
||||||
|
|
||||||
## What's NOT in This Sprint
|
1. [task]
|
||||||
|
2. [task]
|
||||||
|
3. [task]
|
||||||
|
|
||||||
| Feature | Reason |
|
## Acceptance Criteria
|
||||||
|---------|--------|
|
|
||||||
| [cut feature] | [why — scope, complexity, not needed yet] |
|
|
||||||
|
|
||||||
## Agent Prompt
|
- [ ] [observable behavior]
|
||||||
|
- [ ] Relevant repository checks pass
|
||||||
|
- [ ] Documentation/context is updated when behavior or operation changed
|
||||||
|
|
||||||
> Read PROJECT_BRIEF.md, then read docs/sprint-N/plan.md. Execute Sprint N.
|
## Verification
|
||||||
>
|
|
||||||
> First: git pull origin main && git checkout -b feature/sprint-N
|
- Automated: [commands or checks]
|
||||||
>
|
- Manual: [focused scenarios, if useful]
|
||||||
> Close GitHub Issues in commits: "fix: description (Fixes #NN)"
|
- Independent review: required / optional / not needed - [reason]
|
||||||
> Update docs/sprint-N/progress.md after each phase.
|
- QA: required / optional / not needed - [reason]
|
||||||
> When done, push and create PR: git push origin feature/sprint-N
|
|
||||||
> Follow Sections 12-14 of PROJECT_BRIEF.md.
|
## Risks and Decisions
|
||||||
|
|
||||||
|
- [risk or material decision]
|
||||||
|
|
||||||
|
## Next Action
|
||||||
|
|
||||||
|
[owner and immediate next step]
|
||||||
```
|
```
|
||||||
|
|
||||||
## Progress Tracker
|
## Progress Note
|
||||||
|
|
||||||
Create `docs/sprint-N/progress.md` at sprint start:
|
For long-running work, keep a short progress note:
|
||||||
|
|
||||||
```markdown
|
```markdown
|
||||||
# Sprint N — Progress Tracker
|
# [Work Item] - Progress
|
||||||
|
|
||||||
> If context overflows, start a new chat:
|
- Completed: [items]
|
||||||
> "Read PROJECT_BRIEF.md and docs/sprint-N/progress.md.
|
- In progress: [item]
|
||||||
> Continue from where it left off."
|
- Blocked: [issue or none]
|
||||||
|
- Decisions: [material decisions]
|
||||||
## Task Status
|
- Verification so far: [results]
|
||||||
|
- Next action: [specific action]
|
||||||
| # | 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
|
## Dev Handoff
|
||||||
|
|
||||||
Write `docs/sprint-N/done.md` at sprint end:
|
```text
|
||||||
|
Read the repository instructions, PROJECT_BRIEF.md when present, and this plan.
|
||||||
```markdown
|
Implement the in-scope work, run the listed verification, update durable context
|
||||||
# Sprint N — Done
|
when needed, and prepare a pull request. Do not merge.
|
||||||
|
|
||||||
## 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