docs(ai-team-orchestration): add role guidance, PR checklist, QA risk matrix, and sample prompts

skills/ai-team-orchestration/references/anti-patterns.md

@@ -11,3 +11,22 @@
 | Bugs and decisions kept only in chat | Use the repository's issue tracker and durable context | Future sessions can discover them. |
 | QA fixes application source | QA reports behavior; Dev implements fixes | Separation preserves independent verification. |
 | Treating every automated suggestion as a requirement | Assess relevance, confidence, scope, and practical risk | Review should improve the product, not expand scope without limit. |
+
+## Role responsibilities (Do / Don't)
+
+- Producer
+  - Do: Clarify outcome, constraints, acceptance criteria, and explicit exclusions; coordinate reviewers and merge policy.
+  - Don't: Implement or ship code changes that should be reviewed by Dev.
+
+- Dev
+  - Do: Implement the smallest complete solution, run listed verification, include tests, and prepare the PR with verification steps.
+  - Don't: Merge without required checks, failing tests, or without documenting risks and decisions.
+
+- QA (optional)
+  - Do: Independently verify behavior, file reproducible issues, and confirm fixes after Dev applies them.
+  - Don't: Modify application source as a shortcut for failing verification — report and hand back to Dev.
+
+## Decision logging guidance
+
+- Record material decisions in a DECISIONS.md or the repository issue tracker with: title, date, owner, decision summary (1 line), rationale, and link to related PR/issue.
+- Keep entries short and searchable; record the next action when a decision defers work.

skills/ai-team-orchestration/references/brainstorm-format.md

@@ -87,3 +87,20 @@ Each agent reviews from their perspective:
 
 Flag issues and suggest fixes.
 ```
+
+## Sample agent prompts (minimal)
+
+- Producer (short):
+```
+You are Remy, the Producer. Summarize the outcome, constraints, and acceptance criteria in 4 lines max. List required reviewers and whether QA is needed. End with the single next action.
+```
+
+- Dev (short):
+```
+You are Nova+Sage (Dev). Given the plan, produce an implementation checklist: files to change, tests to add, and verification commands. Keep it actionable.
+```
+
+- QA (short):
+```
+You are Ivy (QA). List 6 focused test scenarios (happy path + 5 edge cases) and the exact steps to reproduce each. Include expected results.
+```

skills/ai-team-orchestration/references/project-brief-template.md

@@ -66,5 +66,16 @@ Use this only when the project benefits from durable context across sessions. Ke
 - Dev: implementation and verification
 - QA: optional independent behavioral verification
 
+## Onboarding checklist (add to brief)
+
+- Setup verified: `npm ci` / `pip -r requirements.txt`
+- Tests run: `npm test` / `pytest -q`
+- Lint pass: `npm run lint`
+- Where to find CI logs and deploy dashboards
+
+## Where to record decisions
+
+- Add short entries to DECISIONS.md or create an issue with the decision tag. Each entry should include: title, date, owner, 1-line summary, rationale, and link to PR/issue.
+
 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.
 ```

skills/ai-team-orchestration/references/sprint-plan-template.md

@@ -32,20 +32,41 @@ Use this for substantial work. Small, clear changes can proceed directly from th
 ## Acceptance Criteria
 
 - [ ] [observable behavior]
-- [ ] Relevant repository checks pass
+- [ ] Relevant repository checks pass (example: `npm run lint`, `npm test`)
+- [ ] Tests covering the change are added or validated
 - [ ] Documentation/context is updated when behavior or operation changed
 
 ## Verification
 
 - Automated: [commands or checks]
+  - Example: `npm ci && npm run test` or `pytest -q`
+  - Example: `npm run lint && npm run build`
 - Manual: [focused scenarios, if useful]
 - Independent review: required / optional / not needed - [reason]
 - QA: required / optional / not needed - [reason]
 
+## PR Checklist (add to PR body)
+
+- Branch name follows repo policy (e.g., `feat/`, `fix/`, or `chore/`)
+- Description: short summary, why, and acceptance criteria
+- Verification steps included (commands & manual checks)
+- Tests added or existing tests updated
+- Relevant docs/PROJECT_BRIEF updated if behavior changed
+- Reviewers: @team or specific owners
+- Required checks: list CI jobs that must pass
+- Release notes / changelog entry: yes/no
+
 ## Risks and Decisions
 
 - [risk or material decision]
 
+## QA risk matrix (when to require QA)
+
+- High impact × High uncertainty = QA required
+- High impact × Low uncertainty = QA recommended
+- Low impact × High uncertainty = QA recommended
+- Low impact × Low uncertainty = QA optional
+
 ## Next Action
 
 [owner and immediate next step]