retro_intake:
  cadence: sprint | release | milestone | project-phase | mixed | unclear
  team_shape: colocated | hybrid | distributed | cross-functional | unknown
  current_pain:
    - stale-format
    - low-participation
    - blame-risk
    - too-many-actions
    - no-follow-through
    - remote-friction
    - weak-evidence
    - recurring-same-problems
    - unclear
  evidence_available:
    - previous-actions
    - board-notes
    - ticket-summary
    - metrics
    - customer-feedback
    - playtest-feedback
    - none
  facilitation_need: light | medium | high
  psychological_safety: low | medium | high | unknown
  desired_outcome:
    - identify-themes
    - choose-experiments
    - repair-ritual
    - capture-postmortem-learnings
    - review-old-actions

# Retrospective Brief

## Recommended mode
- Mode: live-facilitated-retro | async-first-retro | hybrid-retro | milestone-postmortem | action-review-reset
- Why this mode fits: ...

## Review of previous actions
| Action | Status | What happened | Keep / close / escalate |
|--------|--------|---------------|--------------------------|
| ... | done/stale/blocked/dropped | ... | ... |

## Evidence considered
- ...

## Top themes
1. ...
2. ...
3. ...

## Facilitation flow
1. ...
2. ...
3. ...
4. ...

## Prompt set
```text
...

### Step 7: Tailor the brief to the mode
Use `references/action-review-and-packet-shapes.md` for stable packet patterns.

Mode-specific reminders:
- **live-facilitated-retro** — timebox discussion and use silent writing first if louder voices dominate
- **async-first-retro** — collect notes in a bounded window, then reserve the live step for clarification and prioritization only
- **hybrid-retro** — make the shared board/doc the primary workspace so remote participants do not get outrun by room talk
- **milestone-postmortem** — include quality, handoffs, readiness, and cross-discipline coordination prompts without drifting into full RCA
- **action-review-reset** — spend the first half on prior commitments and why they failed before collecting anything new

### Step 8: Route adjacent PM work explicitly
Before finalizing, state when the user should switch skills:
- use `task-planning` for next-sprint decomposition, backlog cleanup, or scope slicing
- use `task-estimation` for sizing, confidence, or capacity disagreements
- use `standup-meeting` when the right next move is a lighter daily coordination change

## Output format
Always return a **Retrospective Brief** with these qualities:
- exactly one primary mode
- previous-action review before new action creation
- 3-5 themes maximum
- 1-3 owned actions maximum
- clear distinction between team-owned actions and escalations
- explicit PM-cluster handoffs when the job changes

## Examples

### Example 1: remote team stuck in stale retros
**Input**
> Our sprint retros are the same every two weeks and people barely talk. We’re remote across three time zones.

**Output sketch**
- Mode: `async-first-retro`
- Silent/async collection window before the meeting
- Short live clustering and vote
- 1-2 actions with explicit owner and next-retro review

### Example 2: game milestone postmortem
**Input**
> We just finished a demo milestone for our Unity game. QA found issues late, art handoffs slipped, and the team is frustrated.

**Output sketch**
- Mode: `milestone-postmortem`
- Prompts include handoffs, asset readiness, QA timing, and cross-discipline blockers
- Actions split between team-owned workflow experiments and producer escalations

### Example 3: same action items keep dying
**Input**
> Every retro ends with five good ideas and none of them ever happen.

**Output sketch**
- Mode: `action-review-reset`
- First section audits prior actions
- New action count capped at 1-2
- Notes why prior actions failed and what review hook changes next cycle

## Best practices
1. **Start with prior commitments** — otherwise the retro becomes performative novelty.
2. **Pick the smallest mode that fits** — more templates is not the same as better learning.
3. **Keep action counts brutally small** — a few owned changes beat a wall of wishes.
4. **Preserve non-blame framing** — process reflection dies when people feel individually judged.
5. **Use evidence, not memory theater** — bring sprint outcomes, QA spikes, support load, launch friction, or playtest signal when available.
6. **Route out when the job changes** — planning, sizing, and daily-sync redesign are adjacent jobs, not retro substeps.

## References
- Atlassian Team Playbook, *Retrospective* — https://www.atlassian.com/team-playbook/plays/retrospective
- Scrum.org, *What is a Sprint Retrospective?* — https://www.scrum.org/resources/what-is-a-sprint-retrospective
- Miro, *Remote Retrospective Guide* — https://miro.com/agile/guide-to-remote-retrospectives/
- Parabol, *22 Retrospective Ideas for Ambitious Teams* — https://www.parabol.co/resources/sprint-retrospective-ideas/
- TeamRetro, *Sprint Retrospective Template* — https://ww2.teamretro.com/retro-template/sprint-retrospective/