Multi-Persona Design Review Pipeline

VerifiedCaution

Site presentation review pipeline: evidence capture, parallel multi-persona critics, synthesis, HTML report, calibration gate, and optional fix phase.

Sby Skills Guide Bot
TestingAdvanced
9/13/2026
Claude Code
#design-audit#accessibility#multi-agent#browser-automation#ux-review

Recommended for

Automated summary

Runs a multi-persona presentation review of a site: browser-based evidence capture, parallel critics, synthesis, an HTML report with annotated screenshots, and an optional fix phase.

Strengths

  • Forces a measured facts sheet (computed styles, geometry, contrast pairs) before any critic is spawned, so quantified findings outrank impressions.
  • Runs critics in parallel, narrow lanes (craft, spec conformance, impeccable, personas) and dedupes their output, ranking each finding by how many independent critics back it.
  • Judges the site against its own documents (DESIGN.md, PRODUCT.md, CONTEXT.md) and turns conflicts with those rules into direction questions rather than defects.
  • Delivers one plain-language HTML artifact that sorts findings into clear problems, weak spots, direction questions and doc corrections, and keeps a Praise section to protect what works.

Limitations

  • Tightly coupled to this repository's tooling: bun, agent-browser, Opus subagents, and the presence of DESIGN.md, PRODUCT.md and CONTEXT.md.
  • Covers presentation only; article prose is explicitly out of scope.
  • The fix phase is optional and thinly specified — the main deliverable is a report, not applied changes.
When to use it

Use it to audit an existing site's presentation — layout, typography, information architecture, accessibility, interaction — before committing to a round of fixes.

When not to use it

Avoid it for reviewing article writing quality, for evaluating a design with no reference documentation, or outside an environment where bun and agent-browser are available.

Security analysis

Caution
Quality score90/100

The skill uses powerful tools such as shell commands, browser automation, subagents, and git for legitimate design-review and fix purposes. There is no destructive or exfiltrating behavior, but the execution of build scripts, code modifications, and browser sessions warrants caution, especially because the skill does not declare allowed tools.

Findings
  • •Instructs execution of local build and preview commands (bun run build && bun run preview) and git operations.
  • •Uses browser automation and subagents, which can interact with the local environment and network.
  • •Includes a fix phase that modifies source code and commits, though gated on explicit user approval.
How this analysis is made

Examples

Full review run
Run the design review on this site: own the server with bun run build && bun run preview, capture evidence for every route in src/pages/ plus the interactive states, then spawn the critics and publish the HTML report.
Spec conformance focus
Do a design review, but weight the critics toward spec conformance: diff every measurable claim in DESIGN.md against the facts sheet and list unshipped rules and doc drift separately from real defects.
Apply fixes after the report
The design review report is done — run the fix phase on all the severity-A findings, and leave the direction questions untouched for me to decide.

name: design-review description: Run the multi-persona presentation review of this site — evidence capture, parallel critics, synthesis, HTML report, calibration gate, and optionally the fix phase. disable-model-invocation: true

Design review

A quality pipeline for this site's presentation: layout, typography, information placement, interaction, accessibility. Never the quality of the writing itself. One primary agent (you) owns evidence, synthesis, and the report; subagents are critics with narrow lanes.

Subagents run on Opus (model: "opus"), never Fable. Research/browse-only agents may run on Sonnet.

Judging standard

The site's own documents are the standard: DESIGN.md (system + Rulings), PRODUCT.md (audience, boundaries), CONTEXT.md (vocabulary). A recommendation that conflicts with them is flagged as a direction question for Mathieu, never presented as a defect. Most high-value findings are violations of the site's own rules — hunt those first, they make fixes uncontroversial.

Phase 1 — Evidence

  1. Own the server: bun run build && bun run preview, or restart the dev server yourself — rehype-plugin and content-collection changes only load at server start, and reviewing a stale DOM wastes the whole run.
  2. Use a named browser session per agent: export AGENT_BROWSER_SESSION=<role>; agent-browser set viewport 1440 900; screenshots with --screenshot-format jpeg --screenshot-quality 80 (viewport + --full per route); agent-browser snapshot > a11y-<route>.txt per route. Run agent-browser skills get core if commands fail.
  3. Enumerate routes from src/pages/ (don't trust a remembered list) plus interactive states: art-stage hover, mid-article scroll, contents scroll-spy, copy button, a nonexistent URL.
  4. Produce one facts sheet before spawning critics: computed styles and geometry for the load-bearing claims (sticky positions, link colors, element boxes, overflow widths, contrast pairs). Critics consume it instead of each re-measuring; a finding backed by a computed value outranks an impression.

Phase 2 — Critics (parallel)

Every critic gets the shared brief: evidence paths, the judging standard, the scope rules, the finding schema. Lanes:

  • Craft: visual hierarchy & layout · typography & color · information architecture · accessibility & interaction (live keyboard testing, a11y trees, axe)
  • Spec conformance: diff every measurable claim in DESIGN.md against the facts sheet — unshipped rules and doc drift both count
  • Impeccable: an agent that invokes the impeccable skill in audit mode
  • Personas (browse the live site, report friction only): recruiter with 90 seconds · engineer landing on an article from search · someone trying to know the person

Scope rules (verbatim into every brief):

  1. Presentation only; copy counts only as UI (labels, headers, standfirsts, invitations), article prose is out of bounds.
  2. Findings on known placeholders go to an unranked "Placeholder notes" section.
  3. Deliberate decisions (light-only theme, no hamburger, anything in DESIGN.md Rulings) are evaluated against the docs, not flagged as defects.
  4. Include a Praise section: 2–3 things that work, so synthesis can protect them.

Finding schema: page/state (cite screenshot) · problem · why it matters (tied to the site's goals) · severity · recommendation (referencing existing tokens/components) · confidence. 4–10 findings per critic; a finding without evidence doesn't ship.

Phase 3 — Synthesis and report

Dedupe across critics; the number of independent critics behind a finding is its confidence rank. Sort into: A clear problems (verified, fix-ready) · B weak spots (supported judgment) · C direction questions (conflict with docs or identity — Mathieu decides) · doc corrections (code right, docs stale).

Publish one HTML artifact with embedded annotated screenshots. Write it in plain language: what's wrong, why it matters, how to fix — no design-dialect ("apparatus", "standfirst", "ledger" only where quoting the docs), no jargon compression. Each A-finding carries its concrete fix.

Phase 4 — Calibration gate

Mathieu reads the report and answers freeform. Every accept/reject on a C-question becomes a timeless rule in DESIGN.md's Rulings section — present-tense fact, no dates, no review citations. Nothing from C is implemented without his answer.

Phase 5 — Fix (separate pass, on request)

  • Structural fixes only: fix the mechanism that produced the bug (cascade layering, a real grid track, a shared component), not the symptom. Load codebase-design first.
  • Parallel implementation agents get disjoint file lists and never touch git state (no stash, no checkout); the primary agent owns git.
  • Code comments state constraints, never history or review provenance. Markdown states present-tense fact — no "was retired", no prev-vs-now.
  • Verify each batch in the browser against the Phase 1 screenshots; bun run build and bun run lint gate every commit. Commit and push only when Mathieu says so.

Copy rules (when the run touches words)

  • Calibrate on Mathieu's own writing (src/content/blog/) before proposing anything: plain, direct, complete sentences, concrete numbers, no aphorisms, no editorial cleverness, no em-dashes.
  • Propose via multi-choice variants he picks from or corrects; never ship freeform drafts of his voice. His corrections are final text.
  • Facts about him come only from him or his files. Blank placeholder beats invented specificity.

Deferred backlog

Carried between runs: mobile pass (the scroll-driven art stage is the riskiest untested surface per HANDOFF.md), production-deploy verification, re-review when field reports and final artwork replace placeholders.

From the file to a first result

The download contains exactly the content displayed on this page. This copy may differ from the latest version in the source repository.

View the source and supporting files

This download contains SKILL.md only. Any scripts, references, templates and dependencies are not included. Get the required files from the source, preserving their directory structure, before continuing.

1. Download the file

Download SKILL.md

From the root of a test project, save the file as .skill-downloads/multi-persona-design-review-pipeline-mtz9jqg6/SKILL.md, or use the command below. This folder is for inspecting the skill before installation.

Command for macOS/Linux or WSL: requires a POSIX shell and curl. On Windows without WSL, use the download button and create the folder manually.

mkdir -p '.skill-downloads/multi-persona-design-review-pipeline-mtz9jqg6' && curl --fail --show-error --location 'https://skills-guides.com/api/skills/multi-persona-design-review-pipeline-mtz9jqg6/download' --output '.skill-downloads/multi-persona-design-review-pipeline-mtz9jqg6/SKILL.md.part' && mv '.skill-downloads/multi-persona-design-review-pipeline-mtz9jqg6/SKILL.md.part' '.skill-downloads/multi-persona-design-review-pipeline-mtz9jqg6/SKILL.md'

2. Check prerequisites

Read SKILL.md before using it. If it references scripts or external services, inspect them and prepare the required access in your test environment.

No recognized prerequisites section in this file. This does not mean it is self-contained: libraries, tools and access requirements may be mentioned elsewhere in the content or source repository.

The platforms on this page are catalog indications. The paths below follow tool documentation; they do not prove this skill has been run in those tools. No minimum tool version is confirmed for this listing.

3. Load the skill

After inspection, copy the complete folder into your project using one of the commands below, then open a new tool session. The command stops if a folder with the same name already exists: compare the files before replacing it.

Claude Code
test -f '.skill-downloads/multi-persona-design-review-pipeline-mtz9jqg6/SKILL.md' && test -s '.skill-downloads/multi-persona-design-review-pipeline-mtz9jqg6/SKILL.md' && mkdir -p '.claude/skills' && test ! -e '.claude/skills/design-review' && cp -R '.skill-downloads/multi-persona-design-review-pipeline-mtz9jqg6' '.claude/skills/design-review'

OpenSkills

OpenSkills must already be installed. The local install/read procedure is checked with OpenSkills 1.5.0, which requires Node.js ≥ 20.6.0. Catalog slugs are not resolved automatically.

Official OpenSkills installation
openskills install './.skill-downloads/multi-persona-design-review-pipeline-mtz9jqg6'

openskills read 'multi-persona-design-review-pipeline-mtz9jqg6'

Reading should display the installed file content and its base directory. It does not run the skill or install its dependencies.

For an agent that reads AGENTS.md, then sync the index. This command changes AGENTS.md: review the diff before using it.

openskills sync

Manual method or another tool: attach SKILL.md to a conversation, or open it in an agent that can read files. Include any required supporting resources. No universal folder is recognized by every tool.

4. Try a first task

Use a short, synthetic input: an API endpoint, a small document or an interface brief. In a new conversation, attach the file or give the agent its path, then adapt this request:

Read .skill-downloads/multi-persona-design-review-pipeline-mtz9jqg6/SKILL.md and apply its instructions to this example: [describe a test input]. Identify any missing files, dependencies or access. Produce the result requested by the skill without inventing data or running unreviewed scripts.

Expected result: output matching the skill instructions, or a precise list of missing prerequisites. A read confirmation alone does not validate a first use. If an external resource is unavailable, that path remains untested.

Related skills