oh-my-opencode 4.12.1 → 4.14.0

package/dist/skills/frontend/references/designpowers/vendor/skills/design-retrospective/SKILL.md

@@ -0,0 +1,266 @@
+---
+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:
+
+```markdown
+### 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:
+
+```markdown
+### 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:
+
+```markdown
+### 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`:
+
+```markdown
+### 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:
+
+```markdown
+### 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?
+
+```markdown
+### 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-writer** | [e.g., "User reads everything — content quality matters more than expected"] |
+| ... | ... |
+
+**Open questions for next time:**
+- [Unresolved question that might be relevant in future projects]
+```
+
+### Step 8: Write the Retrospective
+
+Compile everything into a single document:
+
+```markdown
+# Design Retrospective: [Project Name]
+
+**Date:** [YYYY-MM-DD]
+**Duration:** [How long the project ran]
+**Mode:** [direct/auto/mixed]
+**Agents used:** [X of 10]
+
+## Summary
+[3-5 sentences: what was built, what worked, what was hard, what we learned]
+
+## What Worked
+[From Step 2]
+
+## What Didn't Work
+[From Step 3]
+
+## Process Assessment
+[From Step 4]
+
+## Design Debt
+[From Step 5]
+
+## Taste Evolution
+[From Step 6]
+
+## Carry Forward
+[From Step 7]
+```
+
+Save to: `[project-root]/design-retrospective.md`
+
+### Step 9: Add to the Design Record
+
+After the retrospective is written:
+
+1. Invoke `design-memory` to add this project's observations to the record
+2. Record them as descriptions of *how the user designs* (habits, inclinations), with evidence — never as preferences to apply to future work
+3. Update the project history in the record
+
+### Step 10: Present to User
+
+Show the retrospective to the user as a summary:
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+  DESIGN RETROSPECTIVE: [Project Name]
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+  WINS:
+  • [Top 2-3 things that worked well]
+
+  MISSES:
+  • [Top 2-3 things that needed rework]
+
+  TASTE LEARNED:
+  • [Key taste insights from this project]
+
+  DESIGN DEBT:
+  • Open: [count] | Resolved: [count] | Accepted: [count]
+  • Most affected: [persona]
+
+  CARRY FORWARD:
+  • [Top 2-3 lessons for next time]
+
+  EFFICIENCY:
+  • Fix rounds: [count]
+  • User overrides: [count]
+  • Agents used: [X of 10]
+
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+  Your taste profile has been updated.
+  Next project starts smarter.
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+```
+
+## Integration
+
+- **Called by:** `using-designpowers` (after project completion or on user request)
+- **Reads from:** `design-state.md` (including Design Debt Register), taste profile, critique documents, verification results
+- **Writes to:** `[project-root]/design-retrospective.md`
+- **Calls:** `design-memory` (to update taste profile with learnings)
+- **Pairs with:** `design-memory`, `verification-before-shipping`, `designpowers-critique`
+
+## Anti-Patterns
+
+| Pattern | Why It Fails |
+|---------|-------------|
+| Skipping retrospective because the project "went fine" | Even smooth projects teach you something. "Why did this go well?" is as valuable as "why did this go wrong?" |
+| Blaming agents for wrong decisions | Agents are tools. If the output was wrong, the question is what context they were missing, not what they did wrong |
+| Only looking at what failed | Wins are data too. Understanding what worked is how you replicate it |
+| Not adding observations to the design record | Each project should leave the user a richer mirror of how they design. The record isn't applied to future work, but it's only honest if it's kept current |
+| Running retrospective in auto mode | Retrospectives need user reflection. Always run in direct mode with pauses for user input |

package/dist/skills/frontend/references/designpowers/vendor/skills/design-review/SKILL.md

@@ -0,0 +1,123 @@
+---
+name: design-review
+description: "Use when the user wants to evaluate something that ALREADY EXISTS rather than build something new — \"review this\", \"audit this screen\", \"what's wrong with this page\", \"is this accessible?\", or when they share a screenshot, URL, or existing code/markup. Runs the existing reviewers (design-critic, accessibility-reviewer, heuristic-evaluator) in parallel against the artefact and reconciles their findings into one prioritised report — WITHOUT running discovery, strategy, or the full build pipeline"
+---
+
+# Design Review (the review lane)
+
+Most design work is improving something that already exists, not starting from a blank page. This is the **review-only lane**: it takes an existing artefact — a screenshot, a live URL, a prototype, or existing code/markup — and runs it through the same reviewers and reconciliation the full pipeline uses, but **without** discovery, strategy, design, or build.
+
+It's the counterpart to the build lane. The build lane asks "what are we designing?" and creates. The review lane asks "what are we evaluating?" and critiques.
+
+## When to Use
+
+Route here, instead of the build pipeline, when the user already has something:
+
+- "Review / audit / critique this [screen / page / app / flow / component]"
+- "What's wrong with this?" / "How can I improve this?" / "Is this accessible?"
+- They share a **screenshot**, a **URL**, or point at **existing code/markup**
+- They want a usability, accessibility, or craft assessment of work that already exists
+
+If the user wants to *build* something new, use the normal pipeline (`design-discovery` → …). If it's genuinely unclear which they want, ask one question: "Do you want me to review something you already have, or design something new?"
+
+## What this lane skips and why
+
+It deliberately skips discovery, research, strategy, inspiration, planning, and build — there is nothing to build. It does **not** skip accessibility, usability, or craft evaluation. The point is a rigorous, reconciled critique, fast, then a decision about what to fix.
+
+## Process
+
+### Step 1: Get the artefact
+
+Establish what you're reviewing and take it in directly — always evaluate the **actual artefact**, never a description of it:
+
+| Artefact | How to take it in |
+|----------|-------------------|
+| **Screenshot / image** | Read the image directly |
+| **Live URL** | Load and screenshot it (browser tooling); note interactive states |
+| **Existing code / markup** | Read the relevant files; if it runs, screenshot the running build |
+| **A `DESIGN.md` + a build** | Read the spec via `design-md`, then review the build against it |
+
+If you can only get a static image, say so — keyboard, focus, and screen-reader findings will be **inferred, not verified**. Be explicit about that coverage limit.
+
+### Step 2: Capture a lightweight inferred brief
+
+The reviewers normally evaluate against a brief, personas, and principles. In review mode those don't exist yet, so build a **minimal inferred brief** — a few quick questions, not a discovery session:
+
+1. **What is this, and what's the main thing a person is trying to do here?** (the key task)
+2. **Who is it for?** (audience and ability spectrum — if unknown, assume the full spectrum: permanent, temporary, situational)
+3. **What's the quality bar, and what prompted the review?** (shipping prototype vs. flagship; "it feels off" vs. "failed an audit" vs. "low conversion")
+
+Record this in `design-state.md`, clearly marked as **inferred** (reconstructed for review, not authored up front).
+
+### Step 3: Run the three reviewers in parallel
+
+Dispatch the existing reviewer agents **simultaneously** against the artefact and the inferred brief — this is the Reconciliation Protocol's parallel-review step (see `using-designpowers`):
+
+```
+        artefact + inferred brief
+   ┌────────────┼────────────┐
+   v            v            v
+design-critic  accessibility-  heuristic-evaluator
+               reviewer
+   └────────────┼────────────┘
+                v
+          reconciliation
+```
+
+- **accessibility-reviewer** — WCAG/COGA evaluation. On a static image, flags what it can verify vs. only infer.
+- **design-critic** — craft and intent against the inferred brief.
+- **heuristic-evaluator** — Nielsen's 10 + a cognitive walkthrough of the key task from Step 2.
+
+### Step 4: Reconcile
+
+Apply the **Reconciliation Protocol** from `using-designpowers`: classify findings (Aligned / Complementary / Conflicting) and resolve conflicts by its priority rules (accessibility over aesthetics, usability over style, brief over opinion, personas break ties, escalate to the user if unresolvable).
+
+### Step 5: Present one consolidated report
+
+Deliver a single prioritised report — not three separate ones:
+
+```markdown
+# Design Review: [what was reviewed]
+
+**Reviewed:** [artefact + how it was accessed]
+**Inferred brief:** [key task · audience · quality bar]
+**Coverage:** [what was verified vs. inferred — e.g. "static screenshot: visual + content verified; interaction/keyboard inferred"]
+
+## Summary
+[2-3 sentences: overall assessment]
+
+## Findings (prioritised, reconciled)
+### Critical — blocks access or breaks the key task
+- [source(s)] [finding] → [fix] · affects [persona(s)]
+### Major — significantly degrades the experience
+- ...
+### Minor — improvement opportunities
+- ...
+
+## What works well
+- [genuine strengths — review is not only problems]
+
+## Recommendation
+[Ship as-is / fix criticals first / rethink — and the single most important next move]
+```
+
+For each Critical and Major finding, name who it affects and why it matters — not just what's wrong.
+
+### Step 6: Offer next steps (the user decides)
+
+End by handing the decision to the user. Offer the routes that fit the artefact:
+
+- **Fix it** — if it's code you can edit, dispatch `design-builder` with the prioritised fix list.
+- **Track it** — send deferred Minor findings to `design-debt-tracker` so they aren't silently dropped (accessibility debt needs explicit user acknowledgement to accept).
+- **Go deeper** — if the review reveals the problem is *strategic* (the flow itself is wrong, not the execution), recommend dropping into the full pipeline at `design-strategy` or `design-discovery`.
+- **Validate with people** — if findings are contested, suggest `synthetic-user-testing` (persona walkthroughs) or `usability-testing` (real participants).
+
+The review proposes; it does not auto-fix without direction.
+
+## Integration
+
+- **Entry point:** the Build-or-Review fork in `using-designpowers`
+- **Dispatches (in parallel):** `accessibility-reviewer`, `design-critic` (via `designpowers-critique`), `heuristic-evaluator`
+- **Reconciles via:** the Reconciliation Protocol in `using-designpowers`
+- **Hands off to:** `design-builder` (fixes), `design-debt-tracker` (deferred), `design-strategy`/`design-discovery` (if strategic), `synthetic-user-testing`/`usability-testing` (validation)
+- **Records to:** `design-state.md` (inferred brief, findings, reconciliation decisions)

package/dist/skills/frontend/references/designpowers/vendor/skills/design-system-alignment/SKILL.md

@@ -0,0 +1,120 @@
+---
+name: design-system-alignment
+description: "Use when working with or building design systems — tokens, components, naming conventions, theming, or pattern libraries — ensures consistency, accessibility compliance, and systematic thinking"
+---
+
+# Design System Alignment
+
+A design system is a shared language. When components are consistent, accessible, and well-documented, every new screen starts from a strong foundation. This skill ensures design work aligns with existing systems or builds new ones with the right properties.
+
+## When to Use
+
+- A design system already exists and new work must align with it
+- Building new components for an existing system
+- Creating a new design system from scratch
+- Auditing an existing system for consistency or accessibility
+- Defining or modifying design tokens
+
+## Process
+
+### Step 1: Inventory the Existing System
+
+If a design system exists, catalogue:
+- **Tokens:** colours, spacing, typography, shadows, borders, motion
+- **Components:** what exists, what states are covered, accessibility status
+- **Patterns:** common layouts, form patterns, navigation patterns
+- **Documentation:** what is documented, what is tribal knowledge
+- **Gaps:** what is missing, inconsistent, or broken
+
+If no system exists, document what patterns are already in use (even informally).
+
+### Step 2: Token Architecture
+
+Design tokens are the atoms of the system. Structure them in layers:
+
+**Global tokens** — raw values
+```
+color-blue-500: #3B82F6
+spacing-4: 16px
+font-size-base: 1rem
+```
+
+**Semantic tokens** — purpose-driven aliases
+```
+color-primary: {color-blue-500}
+color-error: {color-red-600}
+spacing-element: {spacing-4}
+font-size-body: {font-size-base}
+```
+
+**Component tokens** — component-specific overrides
+```
+button-background: {color-primary}
+button-padding: {spacing-3} {spacing-4}
+input-border-color: {color-neutral-300}
+```
+
+Every token must meet accessibility requirements at the semantic level — if `color-primary` is used for text, it must have sufficient contrast against its background token.
+
+### Step 3: Component Specification
+
+For each component, document:
+
+```markdown
+## [Component Name]
+
+**Purpose:** [What this component is for]
+
+**Variants:** [e.g., primary, secondary, ghost, destructive]
+
+**States:** [default, hover, focus, active, disabled, error, loading]
+
+**Accessibility:**
+- Role: [ARIA role if not implicit]
+- Label: [How it is labelled — visible text, aria-label, aria-labelledby]
+- Keyboard: [How to interact via keyboard]
+- Screen reader: [What is announced in each state]
+- Focus: [Focus indicator style, focus order]
+
+**Tokens used:** [Which design tokens this component references]
+
+**Do:** [Correct usage examples]
+**Do not:** [Incorrect usage examples]
+```
+
+### Step 4: Naming Conventions
+
+Consistent naming makes a system learnable:
+
+- **Components:** PascalCase for components, kebab-case for tokens
+- **Descriptive names:** `AlertDialog` not `Modal2` or `PopupThing`
+- **State modifiers:** consistent pattern (e.g., `--disabled`, `--error`, `--active`)
+- **Size modifiers:** use a scale (sm, md, lg) or semantic names (compact, comfortable, spacious)
+
+### Step 5: Accessibility Audit
+
+For every component in the system, verify:
+
+| Check | Requirement |
+|-------|------------|
+| Colour contrast | All text/background pairings meet WCAG AA minimum |
+| Keyboard access | Every interactive component is reachable and operable via keyboard |
+| Screen reader | Every component announces its role, name, state, and value correctly |
+| Focus indicator | Every focusable element has a visible focus ring |
+| Touch targets | All interactive elements meet 44x44px minimum |
+| Motion | All animations respect prefers-reduced-motion |
+| Resize | Components function at 200% zoom |
+
+### Step 6: Document and Communicate
+
+A design system only works if people use it. Ensure:
+- Every component has usage documentation with examples
+- Accessibility requirements are documented per component, not in a separate "accessibility section"
+- Migration guides exist for any changes to existing components
+- The system is versioned so consumers know when changes occur
+
+## Integration
+
+- **Called by:** `ui-composition` (when components need to align with a system)
+- **Pairs with:** `ui-composition` (visual decisions), `accessible-content` (content patterns within components)
+- **Reviewed by:** `designpowers-critique`

package/dist/skills/frontend/references/designpowers/vendor/skills/designpowers-critique/SKILL.md

@@ -0,0 +1,164 @@
+---
+name: designpowers-critique
+description: "Use when reviewing design work against a plan, design principles, or quality standards — provides structured critique covering design intent, accessibility, consistency, and user impact. This is the Designpowers critique skill — use this instead of the Superpowers design-critique when working within a Designpowers workflow"
+---
+
+# Design Critique
+
+Critique is a structured evaluation of whether the design achieves what it set out to do, for the people it set out to serve — and whether it does so with the craft quality the project demands. This skill ensures review is rigorous, specific, and constructive. When a taste profile exists, critique includes aesthetic evaluation against that profile — not arbitrary personal preference, but the specific emotional target, craft standards, and quality bar the team agreed on.
+
+## When to Use
+
+- After completing a design task or set of tasks
+- Before handoff to engineering
+- When a design decision feels uncertain
+- At scheduled review points in a design plan
+
+## Process
+
+### Step 1: Gather Review Inputs
+
+Before critiquing, assemble:
+- The design brief (from design-discovery)
+- The design plan (from writing-design-plans)
+- The design principles (from design-strategy)
+- The personas (from inclusive-personas)
+- The current design artefacts (mockups, code, prototypes)
+
+### Step 2: Evaluate Against Intent
+
+For each design decision, ask:
+1. **Does it solve the stated problem?** Refer to the design brief
+2. **Does it serve the identified personas?** All of them, not just the primary user
+3. **Does it follow the design principles?** Specifically which principles it upholds or violates
+4. **Does it align with the design system?** If applicable
+
+### Step 3: Craft and Taste Evaluation
+
+If a taste profile exists (from `design-taste`), evaluate the design against it:
+
+**Emotional target:**
+- [ ] Does the design evoke the intended feeling? (Reference the taste profile's emotional target)
+- [ ] Would the user describe this experience with the words in the emotional target?
+
+**Craft standards:**
+- [ ] Spacing has intentional rhythm — not just "correct," but considered
+- [ ] Colour usage follows the restraint/vibrancy rules in the taste profile
+- [ ] Shadows, borders, and radii use a consistent vocabulary
+- [ ] Typography choices serve both readability and personality
+- [ ] The overall composition feels cohesive — like one designer, not a committee
+
+**Reference benchmark:**
+- [ ] This design would sit comfortably next to the taste references
+- [ ] The quality level matches what was agreed (prototype/production/flagship)
+
+**Craft findings format:**
+| Element | Taste expectation | Current state | Gap |
+|---------|------------------|---------------|-----|
+| [Element] | [What the taste profile calls for] | [What exists] | [Specific difference] |
+
+If no taste profile exists, note this as an observation: "No taste profile was created for this project. Craft evaluation is based on general quality standards only."
+
+### Step 4: Accessibility Review
+
+Every critique includes an accessibility evaluation:
+
+**Perceivable:**
+- [ ] All content is available to screen readers
+- [ ] Colour is not the sole indicator of meaning
+- [ ] Contrast ratios meet WCAG AA minimum
+- [ ] Text is resizable to 200% without loss of function
+- [ ] Alt text is present and appropriate
+
+**Operable:**
+- [ ] All interactions are keyboard accessible
+- [ ] Focus order is logical
+- [ ] Focus indicators are visible
+- [ ] Touch targets meet 44x44px minimum
+- [ ] Motion respects prefers-reduced-motion
+- [ ] No keyboard traps
+
+**Understandable:**
+- [ ] Language is plain and clear
+- [ ] Navigation is consistent
+- [ ] Error messages explain the problem and the solution
+- [ ] Form labels are visible and associated
+- [ ] Behaviour is predictable
+
+**Robust:**
+- [ ] Semantic HTML is used correctly
+- [ ] ARIA is used only when necessary and correctly
+- [ ] The design works across supported browsers and assistive technology
+
+### Step 5: Classify Issues
+
+Rate each finding:
+
+| Severity | Definition | Action |
+|----------|-----------|--------|
+| **Critical** | Blocks access for some users or violates the design intent | Must fix before proceeding |
+| **Major** | Degrades experience significantly but does not block access | Should fix before handoff |
+| **Minor** | Improvement opportunity, does not block or significantly degrade | Fix if time allows |
+| **Note** | Observation or suggestion for future iteration | Document for next cycle |
+
+### Step 6: Write the Critique
+
+```markdown
+# Design Critique: [Feature/Task Name]
+
+**Reviewed against:** [Design brief, plan, principles — with references]
+
+**Date:** [YYYY-MM-DD]
+
+## Summary
+[2-3 sentences: overall assessment]
+
+## Craft Assessment
+[Does the design meet the taste profile's quality bar? Emotional target alignment? Reference benchmark?]
+
+## Findings
+
+### Critical
+- [Finding]: [Explanation] → [Recommended action]
+
+### Major
+- [Finding]: [Explanation] → [Recommended action]
+
+### Minor
+- [Finding]: [Explanation] → [Recommended action]
+
+### Notes
+- [Observation]
+
+## Accessibility Status
+[Pass/Fail against WCAG AA with specific gaps]
+
+## Recommendation
+[Proceed / Revise and re-review / Rethink approach]
+```
+
+### Step 7: Present and Discuss
+
+Present findings to the user. For each critical or major issue, explain:
+- What the issue is
+- Who it affects (reference specific personas)
+- What the recommended fix is
+- Why it matters
+
+Critical issues block progress. They must be resolved before moving to handoff.
+
+### Step 8: Record Design Debt
+
+After the critique is complete and the fix round is determined:
+
+1. Identify all **Minor** and **Note** severity findings that will NOT be fixed in this round
+2. Invoke `design-debt-tracker` to capture these as debt items in the Design Debt Register
+3. Each deferred item must include: who is affected, suggested fix, and why it was deferred
+
+Do not silently drop Minor findings. They either get fixed or they get tracked.
+
+## Integration
+
+- **Called by:** `writing-design-plans` (at review checkpoints)
+- **Reviews output from:** `ui-composition`, `interaction-design`, `accessible-content`, `cognitive-accessibility`, `adaptive-interfaces`, `design-system-alignment`
+- **Calls:** Relevant design skills for fixes, `design-debt-tracker` for deferred findings, then `design-handoff` when critique passes