SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsdesign-review

design-review

Design & creation

View repository

Updated 10-16 00:00

About this skill

Design Review

Conduct design specification consistency reviews on prototypes and components in the project, and produce a structured Review report.

Role Definition

You will act as a Design Quality Reviewer × Theme Architect (hybrid role), assisting the user in completing the Design Review.

Core Process

Determine scope and basis → Execute review → Generate report → Append log

Step 1: Determine the review basis

Determine the basis for the design review (design specification) according to the following priority:

  1. User-specified → Design specification documents, themes, or DESIGN.md explicitly provided by the user
  2. Project default theme → AGENTS.md Design system files in the default theme directory defined in

Load the basis files：

Enter the determined theme directory (e.g., src/themes/<theme-key>/), and load in the following order:

  1. DESIGN.md — Design specification document (core basis, highest priority)
  2. globals.css or designToken.json — Design token definitions (choose one, based on the file actually present in the theme)
  3. components/ — Theme components (if any)
  4. templates/ — Page templates (if any)

If the project has no default theme and the user has not specified a basis, then only perform general design quality checks (consistency, accessibility, responsiveness, etc.), and do not perform theme compliance checks.

Step 2: Determine the review scope

Determine the scope of prototypes/components to review according to the following priority:

  1. User explicitly specified → The user directly pointed out the target prototype or directory
    • "Review the homepage" → Review only the homepage prototype
    • "Check all button components" → Review only src/components/ components related to buttons under
  2. Vague user description → The user gives a direction but does not specify precisely
    • "Help me check the pages that were changed recently" → Scan recently changed prototypes/components by timestamp
  3. User did not specify scope (default) → Perform incremental scan (see default process below)

Default incremental scan process：

  1. Read the last Review time → From src/docs/review-log.md obtain the timestamp of the last log entry
  2. Scan changed files → Using that timestamp as the baseline, detect files that have changed since the last Review
    • Scan range:src/prototypes/、src/components/
    • Use find or git diff --name-only to obtain the list of changed files
  3. Generate review list → Display the list of prototypes/components to be reviewed, and wait for user confirmation

First execution: If review-log.md does not exist or is empty, then scan all prototypes and components.

Step 3: Display the review list

Display the scope detection results to the user in the following format:

📋 上次设计 Review：YYYY-MM-DD HH:mm（或「首次 Review」）
🎨 审查依据：<主题名> DESIGN.md

📝 待审查范围：

🔸 原型：
  - xxx-page（新增 / 修改）
  - yyy-page（修改）

🔸 组件：
  - zzz-button（新增）

是否按以上范围执行 Review？

Wait for user confirmation before continuing. The user can adjust the scope at this point.

Step 4: Execute the review

After user confirmation, review the target prototypes/components one by one, producing findings across two dimensions.

Sub-agent delegation (recommended): When the scope to be reviewed contains 3 or more prototypes/components, it is recommended to launch a separate sub-agent (browser_subagent or equivalent mechanism) for each target and execute the review in parallel. Each sub-agent is responsible for:

  1. Reading all source code of the target prototype/component (.tsx / .css / .module.css , etc.)
  2. Executing the Part A check according to the rules below
  3. Returning a structured list of findings (JSON or Markdown table)

After the main process aggregates all sub-agent results, it uniformly generates the Part B recommendations and the final report.

Part A: Specification compliance check

Check basis priority

Each theme has different specifications, therefore the rules defined in the DESIGN.md loaded in step 1 shall prevail, rather than the general checklist below.

Specific priority:

  1. "Prohibited practices" / "Usage constraints · Must comply" in the theme DESIGN.md → corresponds to 🔴 Critical
  2. "Recommended practices" in the theme DESIGN.md → corresponds to 🟡 Warning when violated
  3. Design Tokens defined in the theme DESIGN.md(colors, spacing, border radius, shadows, typography, etc.) → corresponds to 🟡 Warning when hardcoded deviations occur
  4. Component system defined in the theme DESIGN.md → rewriting existing components yourself corresponds to 🔵 Info
  5. General checklist below → only serves as a supplement for dimensions not covered by DESIGN.md
General checklist (supplementary)

The following dimensions are used only when the theme DESIGN.md does not make explicit provisions for that dimension. If DESIGN.md already has more specific requirements, DESIGN.md shall prevail.

Check dimension Check content
Color Whether color variables defined by the design system are used; whether hardcoded color values exist
Font Whether the font family, font size, and font weight conform to the design system definitions
Spacing Whether inner and outer margins use standard spacing values
Border radius Whether border-radius uses the standard values defined by the design system
Shadow Whether box-shadow uses the shadow levels defined by the design system
Component usage Whether components already provided by the theme (Button, Card, Input, etc.) are reused, rather than rewritten yourself
Layout Whether the design system's layout patterns and grid specifications are followed
Accessibility Color contrast (WCAG 2.1 AA), semantic tags, accessibility of interactive elements
Responsive Whether the design system's breakpoint specifications are followed
Severity classification
  • 🔴 Critical — Violating the theme's mandatory rules in "Prohibited practices" or "Must comply"
  • 🟡 Warning — Deviating from "Recommended practices" or hardcoding values already defined by Design Tokens
  • 🔵 Info — Optimization suggestion (e.g., an existing component could be reused but a similar component was implemented yourself)

Part B: Theme extension recommendations

Identify new patterns in the prototype/component that are worth incorporating into the design system:

Identification dimension Description
New design element Colors, fonts, spacing, etc. that appear in the prototype but are not yet defined in the design system and have reuse value
New component patterns UI components implemented independently in the prototype; if they are generic, it is recommended to extract them into the theme components/
Repeated templates Similar page structures/layout patterns appear in multiple prototypes; it is recommended to extract them into the theme templates/
New interaction patterns Interaction patterns that differ from existing components (such as new form validation, loading states, etc.)

Step 5: Generate the Review report

Use the /skills/design-review/references/review-report-template.md template to generate a structured report and display it directly to the user.

The report should include:

  • Review summary (scope, basis, statistics)
  • Part A specification violation list (table)
  • Part B theme extension suggestion list (table)
  • Suggested priority ordering

Step 6: Append the Review log

After the review is complete, append a log entry to src/docs/review-log.md .

  • Log template source:src/docs/templates/review-log-template.md
  • If review-log.md does not exist, first create it based on the template
  • The log uses a compact format, one entry per line
  • When review-log.md reaches or exceeds 500 lines, delete the oldest 50 lines of business logs, then append trim log entries to record the trimming action
  • Logs are append-only; do not rewrite history

Output files

  • Review report: display directly in the conversation (do not write to a file)
  • Review log:src/docs/review-log.md(append)

Constraints

  1. Read-only review — The Review process does not modify any prototype or component code; it only produces suggestions
  2. Do not modify the theme — Part B only provides suggestions and does not automatically modify theme files
  3. User confirmation — The scope and basis must be confirmed by the user before the review is executed
  4. Incremental priority — By default, only review changes since the last Review to avoid repeated reviews

Reference

rules/design-guide.md | rules/theme-guide.md | rules/memory-system-guide.md