/review-design

name: review-design
description: 'Review digital artifacts against the user’s task, creative direction, functional and accessibility requirements, and actual delivery medium. Inspect renders, native files, playback or interaction as appropriate; exercise relevant failure and recovery paths and report evidence-backed findings. Use for design review or a manifest gate. Design guidance belongs to design; implementation and restyling stay with the invoking workflow.'
user-invocable: true

review-design — evaluate a user-visible artifact

Judge whether the audience can understand, engage with and use the artifact as intended, including its purpose-led visual ambition. Review only: you find and explain, the author decides and edits. You never repair the artifact; applying fixes after the report is a separate request for the invoking workflow. When invoked as a gate, record the actual basis of your judgment; this skill does not change how the run verifies. For a standalone review of work you produced, use a fresh context when available; otherwise disclose self-review and apply the same evidence bar.

Input

`$ARGUMENTS` carries what to review — a file path, a directory, a URL, or a running app plus how to reach it. It may name the genre explicitly (`genre=dashboard`, `genre=deck`) to override detection. A manifest gate's Evidence activates this skill under the run's selected evaluator; the gate may name the genre and any pinned references — mocks, examples, or criteria the author fixed during definition, which the evaluation then judges against.

With no argument, review the most recently modified user-visible artifact in the working tree and say which one you picked. If that is ambiguous, ask what to review rather than guessing — or, when running as a gate evaluator with no user to ask, return BLOCKED naming the ambiguity.

Rendered evidence or BLOCKED

A verdict from source inspection alone is not a complete design evaluation. Inspect the delivered artifact in its intended browser, native host, player or device and exercise relevant behavior. Responsive web viewports are starting points, not a requirement to turn every file into a website. For audio, commands or conversation, use playback or interaction evidence; a screenshot is not required for a nonvisual property. Check supported themes, inputs, access and relevant states. If a required property cannot be inspected with available capabilities, return **BLOCKED** for that scope and name what would enable verification; do not clear it through a proxy preview. Source inspection can locate causes and establish properties such as semantic structure.

Standards

Use `../design/SKILL.md` for audience-centered art direction. Treat it as guidance beneath the brief and established design system, not a style-conformance gate. Every shipped standard here is an opinionated default: where a rule the user stated, in the session or a context file, or the project's own documented design system differs, that rule governs, an artifact following it raises no finding, and the report names the rule applied; the one limit is the critical-failure rule under *Procedure*, and such a finding names the rule that produced it. If the companion skill is absent, judge against the supplied brief and references without inventing its defaults.

This evaluator owns the conditional standards below. Load those the artifact's medium and touched domains call for:

| When reviewing | Read | |---|---| | Web access and interaction | `references/floors.md` — requirements, exceptions and behavioral checks | | Structural or quantitative information and information graphics | `references/figures.md` — faithful encoding and equivalent access | | Stateful or shared work, multi-page journeys, presentations, non-web or unfamiliar media | `references/experience.md` — continuity, consequences and actual-medium evidence |

Procedure

1. **Name the genre and use context** you are judging against, in one line, before any finding — a finding graded for the wrong use is noise the author should ignore. An explicit `genre=` argument wins; otherwise detect from the artifact's job, and where detection is genuinely balanced, say so and ask — with no user to ask, judge under the closer use context and name the call in the report. 2. **Recover the intended result and work** from the supplied brief, evidence and requirements before judging the artifact. Name the audience, their relevant path or loop and the information needed together. If intent is unavailable, distinguish what can be assessed from unverified purpose fit. The artifact can reveal its apparent operation; that does not establish that it serves the intended outcome. Do not invent a goal and convict against it. 3. **Run applicable checks.** Use established project tooling and, for HTML, `node scripts/design-check.mjs <artifact.html>` from this skill's directory. Exit zero means completed, not clean. Validate measured candidates and NOTE items against the actual artifact and applicable exceptions before grading; SKIPPED properties remain unverified. Neither selector presence nor a heuristic count establishes a requirement violation or pass. 4. **Render and exercise** per the section above. Run the loop from step 2 yourself, twice, and watch what each pass costs. Use the intended result to select the observation; delivery probes in the loaded standards are starting examples. 5. **For improvements, compare with the incumbent** under matched content, state, output size and useful fidelity. Identify gains and losses in the actual task and visual expression, preserving successful identity and behavior. If the original is unavailable, state that limit rather than claim superiority. 6. **Judge the renders** against the loaded standards, in this order: task fit — whether the arrangement lets that loop run, with what the loop needs together visible together, the repeated action reachable without hunting, and the sequence's order m