Skip to content

Team Coordination Prompts

Ready-to-use prompts for multi-persona team orchestration. Each prompt invokes 2-5 personas with full R.I.S.C.E.A.R. context to address a recurring team activity: standups, sprint planning, architecture reviews, retrospectives, onboarding, handoffs, roadmap reviews, and capacity planning. All prompts include expected output structure and size-based variations.

Table of Contents

  1. Daily Standup Summarization (CO + SMC)
  2. Sprint Planning Facilitation (SMC + BC + BV)
  3. Architecture Review Orchestration (RC + BC + BV + GCA)
  4. Incident Retrospective (IC + DE + BV)
  5. New-Hire Onboarding Plan (DE + CO + RC)
  6. Team Retrospective (CO + SMC + DE)
  7. Cross-Team Handoff Package (CO + DE + BV + SIA)
  8. Technical Debt Discussion (BC + BV + SMC)
  9. Roadmap Review (SMC + RC + BC + BV)
  10. Capacity Planning (SMC + CO)
  11. Blameless Post-Mortem (IC + DE + BV + GCA)
  12. Design Spike Kickoff (RC + BC)
  13. Pull Request Review Synthesis (BV + GCA)
  14. Quarterly OKR Setting (SMC + BC + RC)
  15. Chapter Standards Review (BV + GCA + DE)
  16. Weekly Status Report (CO + SMC + DE)
  17. Persona Customization Proposal (BC + BV + GCA)
  18. Cross-Squad Dependency Mapping (SIA + CO)

1. Daily Standup Summarization

Personas: Collaboration Orchestrator (CO) + SAFe Metrics Crafter (SMC)

Scenario: Distill a 15-minute team standup into a 120-word shared summary with blockers surfaced and decisions recorded.

You are coordinating two personas to summarize a team standup.

TEAM COMPOSITION:
- Collaboration Orchestrator (CO): Facilitation and handoff owner
- SAFe Metrics Crafter (SMC): Velocity and impediment tracker

INPUT: raw standup transcript (stream-of-consciousness, 8 engineers speaking)

CO RESPONSIBILITIES:
1. Extract per-engineer items: yesterday, today, blockers
2. Identify handoffs proposed during the meeting
3. Flag items that need async follow-up

SMC RESPONSIBILITIES:
1. Compute velocity signals: stories completed, stories started
2. Count and categorize impediments (people, process, tools, external)
3. Flag items at risk of missing sprint commitments

COMBINED OUTPUT (max 120 words):

## Standup Summary -- {date}
**Completed yesterday:** bulleted list
**Planned today:** bulleted list
**Blockers:** bulleted list with owner
**Handoffs proposed:** bulleted list (from -> to)
**At risk:** bulleted list with rationale
**Decisions taken:** bulleted list

CONSTRAINTS:
- No personal blame language
- Use first-name references
- Timebox 120 words total
- Surface exactly 0 or exactly 1 most-urgent blocker

Expected Output: Markdown section with five bulleted lists and a single blocker callout. Dated. Posts to team Slack within 10 minutes of standup end.

Variations: - 3-person team: drop per-engineer detail, keep only blockers + decisions - 15-person team: group by squad, surface cross-squad handoffs - 30+ person team: squads-of-squads format with cross-squad blockers only

2. Sprint Planning Facilitation

Personas: SMC + BC + BV

Scenario: Facilitate a 2-hour sprint planning session with capacity modeling, story breakdown, and risk assessment.

You are coordinating three personas to facilitate sprint planning.

TEAM COMPOSITION:
- SAFe Metrics Crafter (SMC): Capacity and velocity modeling
- Blueprint Crafter (BC): Story breakdown and design context
- Blueprint Validator (BV): Feasibility and risk critique

SPRINT CONTEXT:
- Team size: 7 engineers
- Sprint length: 2 weeks
- Historical velocity: 32 story points (rolling 6-sprint avg)
- Sprint goal: {specific goal from product}
- Backlog: top 15 stories, estimated

PHASE 1 -- CAPACITY (SMC leads, 15 min):
1. Compute available capacity: 7 engineers x 2 weeks - OOO - meetings - oncall
2. Set commit target at 80% of capacity, stretch at 95%
3. Publish capacity sheet

PHASE 2 -- STORY BREAKDOWN (BC leads, 60 min):
1. For each committed story: acceptance criteria, design sketch, test plan
2. Identify dependencies between stories
3. Flag stories needing spike before commit

PHASE 3 -- FEASIBILITY CRITIQUE (BV leads, 30 min):
1. For each story: score feasibility (1-5), risk (1-5), novelty (1-5)
2. Challenge any story with feasibility < 4 or risk > 3
3. Propose scope cuts if commit > 95% capacity

PHASE 4 -- DECISION (all three, 15 min):
1. Final committed list
2. Stretch list
3. Explicit de-scoped list with rationale

OUTPUT FORMAT:

## Sprint {N} Plan
**Capacity:** {points}
**Committed:** {points} ({n} stories)
**Stretch:** {points} ({n} stories)
**De-scoped:** {n} stories with reasons
**Risks:** top 3 with mitigation owner
**Dependencies:** diagram or list

Expected Output: Sprint plan document with four sections, ready to paste into team tracker.

Variations: - 3-person team: drop BV phase; BC and SMC share critique - 20+ person team: run per-squad then synthesize cross-squad

3. Architecture Review Orchestration

Personas: RC + BC + BV + GCA

Scenario: 90-minute synchronous architecture review with scoring and structured critique.

You are coordinating four personas for a synchronous architecture review.

DESIGN UNDER REVIEW: {title, 1-line description}

TEAM:
- Research Crafter (RC): Prior-art and constraint context
- Blueprint Crafter (BC): Design author
- Blueprint Validator (BV): Structural critique
- Governance Compliance Auditor (GCA): Policy and standards review

PHASE 1 -- CONTEXT (RC, 10 min):
Pull prior ADRs, related systems, known constraints. Produce a 300-word
context brief with cross-links.

PHASE 2 -- DESIGN WALKTHROUGH (BC, 25 min):
Required sections:
- Problem statement
- Proposed approach
- Alternatives considered (min 2)
- Trade-offs accepted
- Implementation sequence

Attendees ask CLARIFYING questions only. No critique yet.

PHASE 3 -- STRUCTURAL CRITIQUE (BV, 20 min):
Score design on 6 axes (1-5 each):
- Clarity
- Feasibility
- Trade-off rigor
- Testability
- Risk coverage
- Operational readiness

For any axis <= 3, require written mitigation.

PHASE 4 -- POLICY REVIEW (GCA, 15 min):
Check against team constitution and organization standards.
Surface hard-stop, mandatory, preferred conflicts.
Propose resolution for each conflict.

PHASE 5 -- DECISION (all, 10 min):
APPROVE / REVISE / REJECT with written rationale.

OUTPUT FORMAT:

## Architecture Review: {title}
**Decision:** APPROVE / REVISE / REJECT
**Reviewers:** RC, BC, BV, GCA
**Scores:** 6-axis table with 1-sentence justification each
**Policy Findings:** table of conflicts with resolutions
**Mitigations Required:** bulleted list with owners
**Next Review:** date if REVISE

Expected Output: Architecture Decision Record with the above format, filed within 24 hours.

Variations: - Small teams: combine RC + BC, BV + GCA; compress to 60 minutes - Regulated domains: add DGS for data-handling aspects

4. Incident Retrospective

Personas: IC + DE + BV

Scenario: Blameless retrospective 3-5 days after an incident is resolved.

You are coordinating three personas for a blameless incident retrospective.

INCIDENT: {id, severity, duration, impact summary}

TEAM:
- Incident Commander (IC): Timeline and response ownership
- Documentation Evangelist (DE): Post-mortem author
- Blueprint Validator (BV): Root-cause validator

PHASE 1 -- TIMELINE (IC, 15 min):
Reconstruct incident timeline from telemetry, chat logs, and runbook actions.
Format: timestamp (UTC) | actor | action | result.
Identify: time to detect, time to acknowledge, time to mitigate, time to resolve.

PHASE 2 -- ROOT CAUSE (BV, 20 min):
Apply 5-whys to timeline. Distinguish:
- Proximate cause (what failed)
- Contributing factors (what made it worse)
- Systemic cause (why the class of failure is possible)

PHASE 3 -- POST-MORTEM (DE, 30 min):
Draft post-mortem with sections:
- Summary (3 sentences)
- Impact (customers, systems, duration)
- Timeline (table)
- Root Cause
- What Went Well
- What Went Poorly
- Action Items (with owners and dates)

CONSTRAINTS:
- No individual blame language ("the on-call" not "Alice")
- Action items must be concrete and owned
- All conclusions cite timeline evidence

OUTPUT FORMAT:

## Post-Mortem: Incident {id}
(full 7-section document)

## Retrospective Actions
| Item | Owner | Due | Type |
|------|-------|-----|------|
(detect/respond/prevent categories)

Expected Output: Published post-mortem with concrete, owned action items.

Variations: - Critical incidents: add GCA for compliance/customer notification review - Security incidents: involve security team lead before publication

5. New-Hire Onboarding Plan

Personas: DE + CO + RC

Scenario: Generate a 30-60-90 day plan for a new engineer joining an existing team.

You are coordinating three personas to produce an onboarding plan.

NEW HIRE: {level, prior background, target team/role}

TEAM:
- Documentation Evangelist (DE): Curriculum owner
- Collaboration Orchestrator (CO): Social/handoff structure
- Research Crafter (RC): Context gathering

PHASE 1 -- CONTEXT (RC, 20 min):
List: team mission, current roadmap, key systems, active contributors,
prior onboarding docs, and any known rough edges.

PHASE 2 -- CURRICULUM (DE, 30 min):
Build 30-60-90 day plan:

Day 1-30 (Absorb):
- Dev env setup
- Read list (max 10 docs)
- Shadow list (which ceremonies to observe)
- One trivial PR by day 10

Day 31-60 (Contribute):
- Two small features or bugs
- First design review as observer
- One runbook executed

Day 61-90 (Own):
- One medium feature owned end-to-end
- Lead one small design review
- First on-call rotation (if applicable)

PHASE 3 -- SOCIAL STRUCTURE (CO, 15 min):
- Buddy assignment
- Weekly 1:1 cadence
- Coffee chats: list 5 people to meet by day 30
- Checkpoints: day 14, 30, 60, 90

OUTPUT FORMAT:

## Onboarding Plan: {name}
**Buddy:** {name}
**Manager 1:1s:** weekly, 30 min
**Day 14 checkpoint:** {topic}
**Day 30 checkpoint:** {topic}
**Day 60 checkpoint:** {topic}
**Day 90 checkpoint:** {topic}

[30-60-90 tables with tasks and success criteria]

Expected Output: Shared onboarding plan doc with weekly checkpoints.

Variations: - Senior hire: compress to 0-14-30 day plan; emphasize ownership faster - Junior hire: extend to 120 days; more shadowing, smaller first PRs

6. Team Retrospective

Personas: CO + SMC + DE

Scenario: Run a sprint or monthly retrospective and produce committed action items.

You are coordinating three personas to facilitate a team retrospective.

SCOPE: Last {sprint / month}
TEAM SIZE: {n}

TEAM:
- Collaboration Orchestrator (CO): Facilitation and psychological safety
- SAFe Metrics Crafter (SMC): Metrics-informed prompts
- Documentation Evangelist (DE): Captures outcomes

PHASE 1 -- DATA GATHERING (SMC, 10 min):
Present metrics: velocity trend, cycle time, defect rate, deploy count,
on-call hours, incident count. No interpretation yet.

PHASE 2 -- SIGNALS (CO, 20 min):
Facilitate silent write-down then share:
- What went well
- What hurt
- What surprised us

Group similar items. No debate.

PHASE 3 -- INQUIRY (all, 20 min):
Pick top 3 pain items. Ask "why" twice for each. Surface root causes.

PHASE 4 -- COMMITMENTS (CO + DE, 15 min):
For each root cause, produce 1 action item:
- SMART formatted
- Owner assigned (in-room volunteer)
- Due date within next iteration

CONSTRAINTS:
- Max 3 action items per retro (pick the vital few)
- No blame, person-language replaced with system-language
- Action items from prior retro reviewed first

OUTPUT FORMAT:

## Retro {date}
**Metrics:** table
**Went well:** list
**Hurt:** list
**Surprises:** list
**Root causes:** list
**Commitments:**
| Action | Owner | Due | Success Criterion |
|--------|-------|-----|-------------------|
**Prior retro review:** status of last retro's commitments

Expected Output: Retrospective doc with 3 or fewer committed action items.

Variations: - Quarterly retro: extend with theme identification and trend analysis - Distributed team: run async with 48h windows per phase

7. Cross-Team Handoff Package

Personas: CO + DE + BV + SIA

Scenario: Package a system for transfer from one team to another.

You are coordinating four personas to build a handoff package.

HANDOFF: {system} from Team {A} to Team {B}

TEAM:
- Collaboration Orchestrator (CO): Facilitator and acceptance owner
- Documentation Evangelist (DE): Package author
- Blueprint Validator (BV): Completeness validator
- System Integration Architect (SIA): Interfaces and dependencies

PHASE 1 -- INVENTORY (SIA, 3 days):
List everything: code repos, services, dashboards, runbooks, alerts,
on-call rotations, upstream dependencies, downstream consumers, SLAs,
open bugs, tech debt items, customer contacts.

PHASE 2 -- PACKAGE (DE, 5 days):
Produce handoff bundle:
- Architecture overview (C4 context + container)
- Runbook (incident, restart, deploy, rollback)
- Onboarding guide (first 5 days for new owner)
- Known issues list
- Contact escalation path
- Open-question log

PHASE 3 -- VALIDATION (BV, 2 days):
Give incoming team runbook and have them execute 3 scenarios unassisted.
Score completeness. Gate handoff on all 3 passing.

PHASE 4 -- ACCEPTANCE (CO, 1 day):
Joint session:
- Outgoing lead walks through package
- Incoming lead asks 10 questions max
- Both leads sign acceptance document

OUTPUT FORMAT:

## Handoff Package: {system}
**From:** Team {A}
**To:** Team {B}
**Effective Date:** {date}
**Contents:** (list of artifacts with links)
**Validation:** (3 scenarios, pass/fail, evidence)
**Acceptance:** signatures
**Open Risks:** list

Expected Output: Acceptance document, all referenced artifacts findable and maintained.

Variations: - Small systems: compress to 1 week total - Large systems: extend to 6-8 weeks with phased acceptance

8. Technical Debt Discussion

Personas: BC + BV + SMC

Scenario: Quarterly debt review with prioritized payback plan.

You are coordinating three personas for a technical debt review.

SCOPE: {system or team}

TEAM:
- Blueprint Crafter (BC): Debt impact analysis
- Blueprint Validator (BV): Debt risk scoring
- SAFe Metrics Crafter (SMC): Capacity allocation

PHASE 1 -- INVENTORY (BC, 30 min):
Gather current debt items from backlog, issues, Slack complaints,
code comments marked TODO/FIXME/HACK. Normalize to 1-line items.

PHASE 2 -- SCORING (BV, 45 min):
For each item, score:
- Impact if not fixed (1-5)
- Cost to fix (person-days)
- Risk of fixing (1-5)
- Half-life (months before it gets worse)

PHASE 3 -- ALLOCATION (SMC, 30 min):
Compute: 20% of upcoming quarter capacity for debt payback.
Rank items by (impact x half-life) / (cost x risk).
Fit items into available capacity.

PHASE 4 -- DECISION (all, 15 min):
Publish:
- Top 5 debt items to pay down
- Parking lot (deferred items) with revisit date
- Explicitly accepted debt (not paying down, documented why)

OUTPUT FORMAT:

## Debt Review {quarter}
**Total items:** {n}
**Capacity allocated:** {points}
**Paying down:**
| Item | Impact | Cost | Risk | Owner |
|------|--------|------|------|-------|
**Parking lot:** list with revisit date
**Accepted:** list with rationale

Expected Output: Debt payback plan fitting within allocated capacity.

Variations: - Startup/Growth teams: 20% allocation; Seed: 0-10%; Scale: up to 30%

9. Roadmap Review

Personas: SMC + RC + BC + BV

Scenario: Quarterly roadmap review with capacity check and risk analysis.

(Full prompt with 4-phase structure; capacity, synthesis, authoring, critique phases)

You are coordinating four personas for a quarterly roadmap review.

INPUTS: prior roadmap, progress to date, new strategic inputs

TEAM:
- SAFe Metrics Crafter (SMC): Capacity modeling
- Research Crafter (RC): Stakeholder input synthesis
- Blueprint Crafter (BC): Roadmap authoring
- Blueprint Validator (BV): Risk and feasibility critique

PHASE 1 -- CAPACITY (SMC):
Model available capacity across quarter accounting for hiring, attrition,
on-call load, meetings, and a 15% buffer.

PHASE 2 -- INPUTS (RC):
Gather: customer requests, strategic goals, debt backlog, compliance items,
platform requests. Synthesize into themes.

PHASE 3 -- DRAFT (BC):
Produce roadmap v1 with objectives, key results, sequencing, dependencies.

PHASE 4 -- CRITIQUE (BV):
Challenge: over-commitment, dependency conflicts, risk concentration,
missing de-risking spikes.

OUTPUT FORMAT:

## Roadmap {quarter}
**Themes:** 3-5 with narrative
**Objectives:** OKR format
**Timeline:** gantt or list
**Dependencies:** cross-team, external
**Risks:** top 5 with mitigations
**Buffer:** capacity reserved

Expected Output: Roadmap document ready for stakeholder review.

Variations: - Annual roadmap: extend to 2-week process with exec review cycle

10. Capacity Planning

Personas: SMC + CO

Scenario: Compute realistic team capacity for a planning horizon.

You are coordinating two personas to compute team capacity.

HORIZON: {sprint / quarter / half}
TEAM: {n} engineers

TEAM PERSONAS:
- SMC: Capacity modeling and velocity trending
- CO: Meeting/ceremony/interruption overhead

PHASE 1 -- GROSS CAPACITY (SMC):
n engineers x working days x 8 hours

PHASE 2 -- DEDUCTIONS (CO):
Subtract:
- Planned PTO, holidays
- On-call burden (weeks on, hours consumed)
- Recurring meetings (sum per engineer)
- Interview/recruiting load
- Support/interrupt load (based on last quarter)

PHASE 3 -- VELOCITY BASED (SMC):
Cross-check with rolling 6-sprint velocity average.
Flag delta > 20% between models for discussion.

PHASE 4 -- TARGETS:
- Commit target: 80% of lower of two models
- Stretch target: 95%
- Reserve: 15-20% for unplanned work

OUTPUT FORMAT:

## Capacity for {horizon}
**Gross hours:** {n}
**Deductions:** breakdown table
**Net hours:** {n}
**Velocity model:** {n points}
**Commit target:** {points}
**Stretch target:** {points}
**Reserve:** {points}

Expected Output: Capacity sheet ready for sprint/quarter planning.

11. Blameless Post-Mortem

Personas: IC + DE + BV + GCA

Scenario: Formal post-mortem for a production incident affecting customers.

You are coordinating four personas to produce a blameless post-mortem.

INCIDENT: {id, severity, customer impact}

TEAM:
- Incident Commander (IC): Timeline reconstruction
- Documentation Evangelist (DE): Post-mortem authorship
- Blueprint Validator (BV): Root-cause validation
- Governance Compliance Auditor (GCA): Customer/regulatory review

IC: reconstruct timeline with timestamps, actors, actions, outcomes.
BV: apply 5-whys, distinguish proximate/contributing/systemic causes.
DE: draft blameless narrative with sections listed below.
GCA: determine disclosure obligations, draft customer communication.

OUTPUT SECTIONS:
1. Summary (3 sentences)
2. Impact (customers, revenue, duration)
3. Timeline (table)
4. Proximate cause
5. Contributing factors
6. Systemic cause
7. What went well
8. What went poorly
9. Action items (detect / respond / prevent)
10. Disclosure plan

CONSTRAINTS:
- No individual-name blame in text
- Every claim cites timeline evidence
- Action items are concrete, owned, dated
- Customer-facing version drafted separately

Expected Output: Internal post-mortem + customer-facing summary.

12. Design Spike Kickoff

Personas: RC + BC

You are coordinating two personas to scope a design spike.

QUESTION: {specific design question to resolve}
TIMEBOX: {1-5 days}

RC: gather prior art, constraints, open questions.
BC: design 2-3 candidate approaches.

OUTPUT:
- Spike goal (1 sentence)
- Questions to answer (max 5)
- Candidate approaches (2-3)
- Evaluation criteria (weighted)
- Timebox and exit criteria
- Next review date

13. Pull Request Review Synthesis

Personas: BV + GCA

You are coordinating two personas for a PR review.

PR: {title, changed files, delta LOC}

BV: structural critique (correctness, tests, maintainability)
GCA: policy critique (secrets, licenses, style, ADR alignment)

OUTPUT: unified review comment with:
- Summary verdict (LGTM / CHANGES REQUESTED / BLOCKED)
- Structural findings (bulleted)
- Policy findings (bulleted)
- Required changes (checklist)

14. Quarterly OKR Setting

Personas: SMC + BC + RC

You are coordinating three personas for OKR setting.

PHASE 1 -- INPUTS (RC): strategic goals, prior quarter results, feedback.
PHASE 2 -- DRAFT (BC): 3-5 objectives, 2-4 key results each.
PHASE 3 -- REALITY CHECK (SMC): capacity fit, dependency risk.

OUTPUT: quarter OKRs with commit vs stretch on each KR.

CONSTRAINTS:
- Max 5 objectives per team
- Each KR is measurable and time-bound
- No more than 70% committed, 30% stretch

15. Chapter Standards Review

Personas: BV + GCA + DE

You are coordinating three personas for a chapter standards review.

CHAPTER: {backend / frontend / data / security}

BV: review recent patterns for quality drift.
GCA: review compliance of patterns with governance.
DE: update chapter style guide where needed.

OUTPUT: chapter standards update with diff, rationale, adoption plan.

16. Weekly Status Report

Personas: CO + SMC + DE

You are coordinating three personas for a weekly status report.

SCOPE: {team / squad / initiative}

CO: gather updates from all contributors.
SMC: include metrics (velocity, quality signals, risks).
DE: produce 300-word report with structure:
- Shipped this week
- On track next week
- At risk (with mitigation)
- Metrics snapshot
- Asks/blocks for reader

CONSTRAINTS:
- 300 words max
- One at-risk item prioritized
- Metrics always present, never embellished

17. Persona Customization Proposal

Personas: BC + BV + GCA

You are coordinating three personas to propose a persona customization.

TARGET PERSONA: {persona_id}
REQUESTED CHANGE: {diff}

BC: design the customization (why, what, how).
BV: critique design for unintended consequences.
GCA: check customization against governance tiers (hard-stop/mandatory/preferred).

OUTPUT:
- Proposal doc with rationale, diff, impact analysis
- Governance tier verdict (allowed / restricted / blocked)
- Review required (yes/no, by whom)

18. Cross-Squad Dependency Mapping

Personas: SIA + CO

You are coordinating two personas to map cross-squad dependencies.

SCOPE: {N squads}

SIA: enumerate service-level and data-level dependencies.
CO: enumerate process-level dependencies (reviews, approvals, handoffs).

OUTPUT:
- Dependency graph (squad-to-squad)
- Critical path identification
- Risk assessment: dependency concentration, fragile edges
- Recommendations for decoupling

Next Steps