Parallel Review System: Run Four Reviews at Once, Ship Your Best Work Faster

The problem with one-big-review

The default instinct when building a review skill is to cover everything. Accessibility. First-time user clarity. Copy. Motion. Visual hierarchy. Information density. Trust.

One skill. Seven lenses. Long prompt. Long output.

That skill is the one you already built in Your First UX Review Agent. It is a good starting point. It is not the end point.

Here is what happens when a single skill reviews a screen with seven lenses:

• The model surfaces the loudest 5 issues across all lenses
• Two lenses dominate. The rest get one line or get skipped
• Subtle issues (quiet accessibility violations, awkward microcopy) get buried
• Output feels generic because the model averaged across all lenses

This guide teaches the multi-lens pattern. It is the highest-leverage move in the Claude Code Starter Pack.

---

The pattern in one picture

Dispatcher Your screen Each lane reviews independently, you combine the findings

• Lane 01 Review /review-a11y Accessibility, contrast, semantics, focus
• Lane 02 Review /review-first-user New user clarity, what is this, what do I do?
• Lane 03 Review /review-copy Voice and CTAs, clarity, tone, microcopy
• Lane 04 Review /review-edges Error, empty, and loading states

Four narrow specialists. One combined report. You are the editor.

---

Why four, not seven

Parallelism has a ceiling. Beyond 4–5 lanes, three things go wrong:

1. Overlap rises. Two lanes flag the same issue in different words. You spend review time merging.
2. Signal/noise drops. The 20th issue across four lanes is usually noise. Each lane should surface only real findings.
3. Review time compounds. Reading four 300-word reports takes 10 minutes. Eight reports take 25 minutes.

Four is the sweet spot for most screens. Three is often enough. Six is too many.

---

The four reviewers you should build first

These four cover 90% of review value for typical web UI. Build them once. Use them forever.

1. /review-a11y (accessibility)

The most commonly skipped and most legally exposed lens.

Focus:

• Contrast (text, icons, focus states)
• Keyboard reachability
• Interactive target size
• Semantic HTML and ARIA usage
• Image and icon labels

Cap the output at 5 issues. Never let this lane be skipped.

2. /review-first-user (first-time user clarity)

The lens new users bring. They do not know your product.

Focus:

• Can someone tell what this does in 3 seconds?
• Is the primary action obvious?
• Are there too many CTAs competing?
• Is the vocabulary insider-y?

Cap at 5 issues. Written from the perspective of someone who has never heard of the product.

3. /review-copy (voice, microcopy, labels)

The lens that catches what visual review misses.

Focus:

• Button copy (action-specific vs. empty like “Submit”)
• Error messages (actionable vs. vague)
• Empty-state copy
• Buzzwords and marketing fluff in product UI
• Consistency with your voice rules

Cap at 5 issues. Reference your brand voice doc.

4. /review-edges (edge states and resilience)

The lens that most reviewers skip. It is where trust is built or broken.

Focus:

• Loading states
• Empty states
• Error states
• Partial data states
• Long content (truncation, overflow)
• Slow network behavior

Cap at 5 issues. These are the issues customers remember for years.

---

How to build the four skills

Follow the template from Your First UX Review Agent, but make each skill narrower.

Quick starter frontmatter and structure for each:

---
name: review-a11y
description: Accessibility review of a screen. Returns the top 5 blocking or high-severity
  accessibility issues with specific fixes. Covers contrast, keyboard reach,
  target size, semantics, and labels. Invoke any time before shipping.
---

## What to do
I will give you a screen (URL, screenshot, or Figma link).
Apply WCAG 2.2 AA. Flag anything below that floor.

## Rubric
- Contrast: text >=4.5:1, large text and UI >=3:1, non-text elements >=3:1
- Keyboard: every interactive element reachable and visibly focused
- Target size: 44x44 minimum for tap targets, 24x24 for pointer with spacing
- Semantics: buttons are <button>, links are <a>, headings are in order
- Labels: every input has a visible or programmatic label, every image has alt or aria

## Output
Top 5 issues, severity (Blocking/High/Medium), fix, and the WCAG reference.

## Never
- Do not surface cosmetic or taste issues. This is accessibility only.
- Do not skip this review even if the screen "looks fine". Half of accessibility is invisible.

Make the other three (review-first-user, review-copy, review-edges) the same shape with different rubrics. Full copy-paste versions live in the Multi-lens Review Pack template.

---

How to invoke them in parallel

In Claude Code, the trick is dispatching subtasks in one turn. The exact syntax varies slightly by surface, but the pattern is the same.

In Claude Code CLI or IDE extension

Paste this into your conversation:

Review https://example.com/pricing in parallel using four subagents:

1. Subagent A: run /review-a11y
2. Subagent B: run /review-first-user
3. Subagent C: run /review-copy
4. Subagent D: run /review-edges

Each subagent returns its own report. Do not merge them inside the subagents.
After all four return, produce a combined report grouped by severity,
deduplicating overlap.

Claude dispatches four parallel subtasks. Each runs its skill. The parent agent collects the reports and combines them for you.

Why the parent does the merge

Letting each subagent merge or deduplicate is a common mistake. The subagents do not know what the others found. They cannot deduplicate intelligently.

The parent is the editor. Its whole job is to read all four reports, drop duplicates, rank by severity, and hand you one list.

---

What the combined report should look like

After the parent merges, you should see something like this:

# Combined review: pricing page

## Blocking (ship stoppers)

1. **Contrast: CTA on green background**
   - From: review-a11y
   - Text contrast 3.1:1 (below WCAG AA).
   - Fix: darken text to #0A2A1E or switch CTA to dark bg.

## High priority

2. **Primary action unclear on first scroll**
   - From: review-first-user
   - Two CTAs ("Get started" and "Request demo") at equal weight confuse choice.
   - Fix: de-emphasize "Request demo" to secondary button style.

3. **"Get started" is a generic CTA**
   - From: review-copy
   - Replace with action-specific verb ("Start 14-day trial", "Create account").

4. **Pricing page has no empty or error state**
   - From: review-edges
   - If pricing fails to load, no fallback UI shown.
   - Fix: add skeleton loader and error state for pricing API.

## Medium priority
[...]

Clean. Grouped by severity. Attributed to the lane that caught it. Actionable.

---

A real example, start to finish

The multi-lens review caught an issue that would have caused a real customer problem. This is the kind of catch you cannot make up the ROI for after the fact.

---

When parallel is overkill

Multi-lens is not always the right answer. Skip it when:

• The screen is experimental or throwaway. Noodle with one skill, ship, move on.
• You are in the first 10 minutes of a new design. Too early for review.
• You only need one lens. If you know the page is mainly a copy problem, just run /review-copy. Don’t dispatch four skills when one would do.

---

The three-layer review practice

Once multi-lens is part of your workflow, you can stack it into a review practice that scales.

Layer 1: While designing (cheap, fast)

Run /ux-review or one specific lane (usually /review-first-user). 1 skill, 1 minute, fast feedback.

Layer 2: Before ship (parallel, thorough)

Run the 4-lane parallel review. 3 minutes, full coverage. This is the ship gate.

Layer 3: After ship (continuous)

Once a week, run the parallel review on the most important pages in production. Catch regressions. Track improvements.

Three layers, three cadences, same four skills. The setup cost is paid once. The benefit compounds.

---

If something stops working, check the Parallel review section of Common failure modes.

---

Checklist: you are done when

---

What this unlocks

Once you have the 4-lane review working, your practice changes in three ways:

1. You ship more confidently. Every important screen gets a real review before going out. No more “I’ll get to it next week.”
2. You catch the quiet failures. The edge-state lane catches things nobody else reviews. That is where customer trust lives.
3. You can layer more lanes for specific projects. Building a data-heavy dashboard? Add /review-density and /review-charts. Building a mobile app? Add /review-thumb-zone. The pattern is extensible.

You have gone from no reviewer, to one reviewer, to a panel. That is orchestration at the practical level. Four specialists working in parallel, you as the editor. This is what the role looks like now.

Exercise

Run a real 4-lane parallel review on a page you are about to ship

45 min

1. Create the four narrow skill files in ~/.claude/skills/

   Create four files: ~/.claude/skills/review-a11y/SKILL.md, ~/.claude/skills/review-first-user/SKILL.md, ~/.claude/skills/review-copy/SKILL.md, ~/.claude/skills/review-edges/SKILL.md. Use the frontmatter and structure from this guide. Cap every skill’s output at five issues. Each skill gets ONE lens only. Resist the temptation to let the copy skill also flag accessibility.

   • All four SKILL.md files exist and each has name: and description: frontmatter
   • Each rubric section covers only that lens (no overlap with another skill)
   • Each skill ends with an explicit cap (“Return at most 5 issues”)
   • Running /review-a11y in Claude Code triggers that specific skill, not a generic review

2. Dispatch all four in parallel on a live URL

   Pick a page you are about to ship (or already shipped but never reviewed). Paste the URL into the prompt. Run it. Wait two or three minutes. Read the combined report. Pick the Blocking issues and fix them today. Do not fix the Mediums this session. The point of the exercise is to feel the difference between one skill and four.

   • Four separate reports came back, each under five issues
   • The combined report is grouped by severity and attributes each issue to its lane
   • The review-edges lane caught at least one issue the other three missed (empty state, error state, loading state). If it did not, your page is unusually resilient or the skill rubric is too soft.
   • You fixed the Blocking issues within the same session, not “next week”

   Review [PASTE URL HERE] in parallel using four subagents:
   
   1. Subagent A: run /review-a11y
   2. Subagent B: run /review-first-user
   3. Subagent C: run /review-copy
   4. Subagent D: run /review-edges
   
   Each subagent returns its own report. Do not merge inside the subagents.
   After all four return, produce a combined report grouped by severity,
   deduplicating overlap. Do not drop any Blocking or High issues.

   Copy dispatch prompt