/design-retrospective

name: design-retrospective
description: Use after shipping or completing a design project — structured reflection on what worked, what didn't, and what taste decisions landed. Adds observations to the design record (design-memory) about how the user designs — a descriptive journal, not preferences applied to future projects

Design Retrospective

A retrospective is not a post-mortem. Post-mortems examine failures. Retrospectives examine the whole process — wins, misses, surprises, and taste evolution. This skill runs after a project ships and turns hindsight into foresight for the next one.

When to Use

• After `verification-before-shipping` passes and the project is declared complete
• When the user says "let's reflect" or "what did we learn?"
• At natural project milestones (end of a major phase, end of a sprint)
• When restarting work on a project after a break — retrospect on what came before

Process

Step 1: Gather Evidence

Before reflecting, assemble the full record:

1. **Read `design-state.md`** — the decisions log, handoff chain, and open questions 2. **Read the taste profile** — what was known at the start vs now 3. **Review user overrides** — every correction, redirect, and override from the handoff chain 4. **Review critique findings** — what the design-critic and accessibility-reviewer flagged 5. **Review fix rounds** — how many, what was fixed, what kept coming back 6. **Check the original brief** — compare what was asked for vs what was delivered

Step 2: Evaluate What Worked

For each major design decision that survived to shipping:

### What Worked

| Decision | Why It Worked | Evidence |
|----------|--------------|----------|
| [Decision from state log] | [Why this was the right call] | [User approved, critic passed, no fix rounds needed] |
| ... | ... | ... |

Look for:

• Decisions that sailed through critique without issues
• Choices the user explicitly praised
• Patterns that emerged naturally and felt right
• Accessibility approaches that enhanced rather than constrained the design
• Moments that revealed something characteristic about how the user designs (to note in the record — not to apply later)

Step 3: Evaluate What Didn't Work

For decisions that required rework, debate, or user correction:

### What Didn't Work

| Decision | What Went Wrong | Root Cause | Fix Rounds |
|----------|----------------|------------|------------|
| [Original decision] | [What happened] | [Why it happened — misread brief? ignored taste? wrong assumption?] | [How many iterations to fix] |
| ... | ... | ... | ... |

Look for:

• Decisions the user overrode — what signal did we miss?
• Findings that came back in multiple fix rounds — why wasn't it caught earlier?
• Accessibility issues that should have been caught in design, not review
• Moments where agents converged on a direction too quickly (a debate might have helped)
• Taste profile mismatches — did we apply an old preference to a new context?

Step 4: Process Evaluation

Evaluate the workflow itself, not just the output:

### Process Assessment

**Pipeline efficiency:**
- Agents dispatched: [X of 10]
- Agents skipped: [list and why]
- Fix rounds: [count] — [were they necessary or preventable?]
- Mode used: [direct/auto/mixed] — [did the mode serve the project?]

**Handoff quality:**
- Were handoff messages specific enough?
- Did any agent miss context from the previous agent?
- Were there gaps where information was lost between agents?

**Debate moments:**
- Were there decisions that should have been debated but weren't?
- Were debates held that didn't need to be?
- Did debate outcomes hold, or were they revisited?

**User engagement:**
- How often did the user override or redirect?
- Were overrides concentrated in one area? (signals a systematic gap)
- Did the user switch from auto to direct? (signals the system missed something)

Step 5: Design Debt Review

Review the Design Debt Register from `design-state.md`:

### Design Debt

**Register status:**
- Total items created: [count]
- Resolved: [count] ([percentage])
- Accepted: [count] — [were these the right trade-offs?]
- Still Open: [count] — [should any escalate?]
- Escalated during project: [count]

**Debt patterns:**
- Most affected persona: [name] — [X items affect them]
- Most common source: [design-critic/accessibility-reviewer]
- Average age of open items: [duration]

**Debt health:**
- [ ] Are we resolving debt faster than we create it?
- [ ] Are the same types of issues recurring? (signals a systemic problem)
- [ ] Did any accepted debt turn out to matter more than expected?

Step 6: Taste Evolution

Note what this project revealed about how the user designs, to add to the observational record. This is *describing* the user's habits, not setting rules for future work:

### What this project revealed (observations for the record)

**Recurring decisions reinforced:**
- [Observation] — now seen in [N] projects, per [evidence]

**New habits or inclinations noticed:**
- [Observation] — first seen here, per [evidence]

**Things the user moved away from:**
- [Observation] — corrected/reversed because [reason]

**Surprises:**
- [What was characteristic or unexpected about how they decided] — e.g. chose [X] over [Y]

_(All recorded as descriptions of how the user designs — never as preferences to apply to future work.)_

Step 7: Carry-Forward Items

What should the next project know?

### Carry Forward

**For the next project:**
- [Lesson learned that applies broadly]
- [Process improvement to try]
- [Taste insight to remember]

**For specific agents:**
| Agent | Lesson |
|-------|--------|
| **design-lead** | [e.g., "User prefers to see colour options before committing — show swatches, not descriptions"] |
| **design-strategist** | [e.g., "Spend more time on the navigation model early — it affected everything downstream"] |
| **content-w