New: 98,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

Design Review

by Owl-Listener in Owl-Listener/designpowers

A skill your agent uses 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…

MITAuto-check passedFrontend & Design

Install Design Review

skills CLI
$ npx skills add Owl-Listener/designpowers --skill design-review -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install Owl-Listener/designpowers design-review --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/Owl-Listener/designpowers.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/design-review .claude/skills/design-review && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
design-review
GitHub stars
251
Token cost
~1.7k tokens
SKILL.md length
739 words
Files
1
Skills in repo
33
Repo updated
First seen
Licence
MIT

At a glance

A skill your agent uses 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…

  • Works in 6 steps: Get the artefact → Capture a lightweight inferred brief → Run the three reviewers in parallel → …
  • The user wants to evaluate something that ALREADY EXISTS rather than build something new — review this
  • SKILL.md covers When to Use, What this lane skips and why, Process and Integration
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

Design Review is an agent skill from Owl-Listener/designpowers. 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

Its SKILL.md is about 1.7k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Frontend & Design, covering Design review and critique, CI/CD and Accessibility. The repository describes itself as: An agent design team you control: 10 agents that run an inclusive design process while you direct. The licence is MIT.

When your agent uses it

  • The user wants to evaluate something that ALREADY EXISTS rather than build something new — review this
  • Audit this screen
  • Whats wrong with this page
  • Is this accessible?

Example prompts

  • “review this”
  • “audit this screen”
  • “s wrong with this page”
  • “/design-review”

Workflow steps

6 steps, taken from the step headings in SKILL.md.

  1. Get the artefact
  2. Capture a lightweight inferred brief
  3. Run the three reviewers in parallel
  4. Reconcile
  5. Present one consolidated report
  6. Offer next steps (the user decides)

What it can do on your machine

Read from SKILL.md and the folder at commit cb00757. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md (its code samples are markdown).

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Design Review loads about 1.7k tokens when it runs. Until then it costs about 128 tokens; SKILL.md has 739 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~128
When it runs · the whole SKILL.md, loaded when a task matches
~1.7k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from Owl-Listener/designpowers at commit cb00757, republished under its MIT licence (© Owl-Listener). 739 words, ~1,749 tokens.

Download SKILL.mdSave it as .claude/skills/design-review/SKILL.md (or your agent's skills folder).
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:

ArtefactHow to take it in
Screenshot / imageRead the image directly
Live URLLoad and screenshot it (browser tooling); note interactive states
Existing code / markupRead the relevant files; if it runs, screenshot the running build
A DESIGN.md + a buildRead 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).

Show full SKILL.md (292 more words)Show less
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)

© Owl-Listener, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in skills/design-review of Owl-Listener/designpowers.

Open the folder on GitHubat commit cb00757

Compare with similar skills

Design Review next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Design Review compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Design Review this skillOwl-Listener/designpowers251—~1.7kAutomated safety check: PassMIT
Design AuditAThevon/genjutsu440—~1.6kAutomated safety check: PassCustom licence
Critique Theaternexu-io/open-design100k—~640Automated safety check: PassApache-2.0
Design FlowOwl-Listener/inclusive-design-skills105—~528Automated safety check: PassMIT
Web Interface Guidelines Reviewervercel-labs/openreview1.7k97 repos~308Automated safety check: PassNone
Vrtmarigold-ui/marigold146—~787Automated safety check: PassMIT

Similar skills

  • Design Audit

    AThevon/genjutsu

    Design audit checklist - motion gaps, accessibility, color consistency, responsive, performance.

    440 GitHub stars~1.6k tokensUpdated 5 days ago
    Frontend & DesignAuto-check passed

  • Critique Theater

    nexu-io/open-design

    Five-dimension design quality review — score the artifact against craft, brand, accessibility, and copy, then fix what falls short before handing it over.

    100k GitHub stars~640 tokensUpdated yesterday
    Frontend & DesignAuto-check passed

  • Design Flow

    Owl-Listener/inclusive-design-skills

    Design an interaction flow with inclusive input and output options from the start.

    105 GitHub stars~528 tokensUpdated 4 mo ago
    Frontend & DesignAuto-check passed

  • Web Interface Guidelines Reviewer

    vercel-labs/openreview

    Official

    Review UI code for Web Interface Guidelines compliance. Use when asked to "review my UI", "check accessibility", "audit design", "review UX", or "check my…

    1.7k GitHub starsUsed in 97 repos~308 tokens
    Frontend & DesignAuto-check passed

  • Vrt

    marigold-ui/marigold

    DST — Trigger the Visual-Regression-Tests (Chromatic) GitHub Actions workflow on the current or a given branch.

    146 GitHub stars~787 tokensUpdated yesterday
    Frontend & DesignAuto-check passed

  • Frontend Design

    jwynia/agent-skills

    Create distinctive, production-grade frontend interfaces with high design quality.

    170 GitHub stars~3.2k tokensUpdated 7 mo ago
    Frontend & DesignAuto-check passed

More from Owl-Listener/designpowers

All 33 skills in this repo

  • Adaptive Interfaces

    Owl-Listener/designpowers

    A skill your agent uses when designing for user preferences — motion sensitivity, contrast needs, colour schemes, text sizing, information density, or any interface behaviour that should adapt to…

    251 GitHub stars~1.1k tokensUpdated 3 mo ago
    Auto-check passed

  • Design Debate

    Owl-Listener/designpowers

    A skill your agent uses when a design direction is uncertain, when the team could go multiple ways, or when the user wants to see competing approaches argued before committing — orchestrates…

    251 GitHub stars~2.1k tokensUpdated 3 mo ago
    Auto-check passed

  • Design Debt Tracker

    Owl-Listener/designpowers

    A skill your agent uses when critique or review produces deferred findings, when checking accumulated design compromises, or when deciding what to address in the next iteration.

    251 GitHub stars~2.2k tokensUpdated 3 mo ago
    Auto-check passed

  • Design Discovery

    Owl-Listener/designpowers

    You MUST use this before any creative or design work — building features, creating components, designing interfaces, modifying user-facing behaviour.

    251 GitHub stars~2.1k tokensUpdated 3 mo ago
    Auto-check passed

  • Design Handoff

    Owl-Listener/designpowers

    A skill your agent uses when design work is complete and needs to be communicated to engineering — creates specifications, documents rationale, accessibility requirements, and interaction details in…

    251 GitHub stars~1.1k tokensUpdated 3 mo ago
    Auto-check passed

  • Design State

    Owl-Listener/designpowers

    A skill your agent uses when any Designpowers agent starts work or completes work — maintains the shared design state file that all agents read from and write to.

    251 GitHub stars~1.6k tokensUpdated 3 mo ago
    Auto-check passed

Categories

Questions about Design Review

What does Design Review do?

A skill your agent uses 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…. Design Review is an agent skill from Owl-Listener/designpowers.", or when they share a screenshot, URL, or existing code/markup.

When should I use Design Review?

Design Review fits situations like: the user wants to evaluate something that ALREADY EXISTS rather than build something new — review this; audit this screen; whats wrong with this page; is this accessible?.

How do I install Design Review in Claude Code?

Run `npx skills add Owl-Listener/designpowers --skill design-review -a claude-code`. Or copy the skill folder (skills/design-review in Owl-Listener/designpowers) into .claude/skills/design-review in your project. Claude Code loads it when a task matches its description.

How do I install Design Review in Codex?

Run `npx skills add Owl-Listener/designpowers --skill design-review -a codex`. Or copy the skill folder (skills/design-review in Owl-Listener/designpowers) into .agents/skills/design-review in your project. Codex loads it when a task matches its description.

Can I use Design Review in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add Owl-Listener/designpowers --skill design-review -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/design-review, .gemini/skills/design-review, .github/skills/design-review and .opencode/skills/design-review in your project.

What does Design Review need to run?

SKILL.md names no scripts, command-line tools or credentials: Design Review is instructions for the agent only.

Does Design Review access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Design Review safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Design Review use?

Design Review is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Design Review use?

About 1.7k tokens (SKILL.md is roughly 7k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Design Review?

Skills that share tags, products or a category with Design Review: Design Audit (AThevon/genjutsu, 440 stars), Critique Theater (nexu-io/open-design, 100k stars), Design Flow (Owl-Listener/inclusive-design-skills, 105 stars) and Web Interface Guidelines Reviewer (vercel-labs/openreview, 1.7k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Design Review?

Owl-Listener (a GitHub user) maintains it in Owl-Listener/designpowers, which has 251 GitHub stars. The repository holds 33 skills in this directory. The repository was last updated on June 23, 2026.

Source: Owl-Listener/designpowers on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.