Purpose
Turn a messy pile of design feedback from multiple reviewers into a single, deduplicated, priority-ranked revision plan — surfacing conflicts, separating opinion from usability problems, and telling the designer exactly what to change first. Eliminates the "which of these 40 comments actually matter" bottleneck after every critique round.
When to Use
Invoke this skill when the user asks to:
- Consolidate design feedback from multiple reviewers or stakeholders
- Resolve conflicting or contradictory comments on a design
- Prioritize a long list of critique notes into what to fix first
- Prepare a revision plan after a design review, critique session, or async comment thread
- Distinguish subjective preferences from real usability or accessibility issues
- Summarize a Figma/Slack/email feedback dump into actionable next steps
Inputs Required
Before starting, collect:
- Raw feedback: All comments, pasted verbatim, ideally with reviewer names/roles attached
- What's being reviewed: The artifact (screen, flow, component, brand asset) and its current stage (concept / wireframe / hi-fi / pre-ship)
- Design goal: The primary objective the design must serve (conversion, clarity, task completion, brand fit, etc.)
- Reviewer roles: Who each reviewer is (PM, eng, exec, other designer, customer) — used for weighting
- Constraints: Deadline, engineering effort limits, brand/design-system rules that override preference
- Decision owner: Who has final say when feedback conflicts (default: the requesting designer)
If reviewer roles are not attached to comments, infer weighting from content and note the assumption. If no decision owner is given, treat the requesting designer as the arbiter.
Instructions
Step 1: Normalize and Deduplicate
Break every piece of raw feedback into atomic comments — one comment = one distinct request or observation.
- Merge near-duplicates and note reviewer count per merged item (e.g., "raised by 3 reviewers")
- Strip filler and rewrite each comment as a clear, neutral statement of the issue
- Discard non-actionable comments (pure praise, vague vibes) but keep a short "affirmed strengths" list from them
Step 2: Classify Each Comment by Type
Tag every comment with one type — this determines how it should be weighted:
- Usability/Functional: Affects whether a user can complete the task (highest inherent weight)
- Accessibility: Contrast, tap targets, screen-reader, keyboard nav (non-negotiable — treat as blocking)
- Design-system/Consistency: Deviates from established components, tokens, or patterns
- Content/Copy: Labels, microcopy, hierarchy of information
- Visual/Aesthetic: Spacing, color, typography treatment — often subjective
- Preference/Opinion: "I'd personally..." with no stated user or business rationale (lowest inherent weight)
Step 3: Group by Theme
Cluster comments into 4–8 themes (e.g., "Navigation clarity," "CTA hierarchy," "Form friction," "Brand alignment"). Themes reveal systemic issues that scattered comments hide — three separate complaints often point to one root cause.
Step 4: Detect and Resolve Conflicts
Identify every pair of comments that pull in opposite directions.
- State the conflict plainly: Reviewer A wants X, Reviewer B wants Y
- Recommend a resolution using this hierarchy: accessibility > design goal alignment > usability evidence > design-system rules > seniority/role weight > majority > designer's judgment
- Where the conflict is genuine preference-vs-preference, escalate it explicitly to the decision owner rather than picking silently
Step 5: Score and Rank Every Comment
Assign each surviving comment three labels:
- Severity: Blocking / High / Medium / Low (accessibility and task-breaking usability start at High or Blocking)
- Effort: S / M / L (rough implementation cost)
- Consensus: number of reviewers who raised it
Rank the full list by: Blocking first, then High-severity/low-effort ("quick wins"), then High-severity/high-effort, then Medium, then Low. Within ties, higher consensus wins.
Step 6: Produce the Revision Plan
Deliver the ranked, numbered action list plus a short "do not change" section for items to explicitly defend (things reviewers requested that would hurt the design goal), with a one-line rationale each.
Output Format
- Structure: Summary header → thematic groupings → conflict resolutions → ranked action list → do-not-change list → affirmed strengths
- Length: 700–1,100 words, scaling with volume of input feedback
- Format: Ranked action list as a numbered table (Rank | Action | Theme | Type | Severity | Effort | Consensus); everything else as tight scannable sections
- Sections: Feedback Summary → Themes → Conflicts & Resolutions → Ranked Revision Plan → Do Not Change → Affirmed Strengths
- Tone: Design lead running a critique — decisive, evidence-first, comfortable overruling opinion when the goal demands it
Quality Checklist
Before delivering output, verify:
- [ ] Every raw comment is accounted for — merged, ranked, or explicitly discarded (nothing dropped silently)
- [ ] Each ranked item carries a Type, Severity, Effort, and Consensus label
- [ ] All accessibility items are marked Blocking or High — none buried as Low
- [ ] Every detected conflict has a stated resolution or explicit escalation — no unresolved contradictions left in the plan
- [ ] The ranked list leads with blocking issues and quick wins, not with easy aesthetic tweaks
- [ ] The "Do Not Change" section defends the design goal against at least the most damaging requested change (when one exists)
Notes
- Weighting by role is a tool, not a rule — a junior designer's usability catch outranks an exec's color preference. State the rationale so the weighting is defensible.
- When three or more distinct comments cluster in one theme, treat the theme as the real problem and address the root cause rather than patching each comment.
- Preference-vs-preference conflicts are the most political — escalate them cleanly to the decision owner instead of absorbing the risk of choosing.
- If feedback volume is very high (50+ comments), lead with the top 10 ranked actions and append the full table, so the designer can start immediately.
How to use this skill
This file is a Claude Code skill in Anthropic's standard format — markdown with YAML frontmatter at the top.
Installing in Claude Code:
~/.claude/skills/<folder-name>/SKILL.md— auto-loads in every session anywhere on your machine (recommended for skills you'll use across multiple projects)<your-project>/.claude/skills/<folder-name>/SKILL.md— auto-loads only when working in that project (recommended for project-specific skills)
Restart Claude Code or open a new session to register.
Using in Claude.ai, ChatGPT, Gemini, or other AI tools:
- Drag this file into a new chat, or copy and paste its contents
- Send your task or request as your next message — the AI will apply the skill where it fits
For Claude Code skill details: https://docs.anthropic.com/en/docs/claude-code/skills