agentleFS
Sign inStart free
smiling66652smiling66652/workbuddy-skill-toolkits/design-review/SKILL.md

design-review

Skill1 starsChanged 48 days agoMITView on GitHub

视觉交付质量门：10 份专项参考（排版/色彩/间距/动效/反模式/对齐/响应式/UX文案/灵感/假数据） + 3 个可执行的 Python 检查脚本（反模式扫描、状态完整性、无障碍语义），附交付前自检清单。 触发词：设计评审、设计审查、视觉走查、design review、UI走查、交付前检查、质量门、 反模式检查、交互状态检查、无障碍检查、对比参考、设计自查、配色是否多余、间距检查 不用于：从零定美学方向（走 frontend-design-guidelines）；WCAG 逐条合规审计（走 accessibility-audit） 注：正文含原作者（Aaron）个人化表述与 memory/channels 路径，本机不存在，按清单与脚本用即可。

We split this skill into the rules it gives an agent

18 rules. 0 are common, 15 are distinctive, and 3 are very specific to this project.

  • 0

    Common

    Most of the 121 edited versions we read keep these.

  • 15

    Distinctive

    This author's own choices. Worth a look.

  • 3

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Before presenting ANY visual or UX work.

    line 20
  2. Distinctive:

    Treat this as a quality gate, not optional polish.

    line 21
  3. Very specific:

    Read guidelines.md or equivalent design system doc first if it exists.

    line 27
  4. Distinctive:

    Follow the project's existing components, tokens, and patterns before inventing anything.

    line 28
  5. Distinctive:

    If no formal guidelines exist, inspect the existing product and match its logic.

    line 29
  6. Distinctive:

    Check how similar tools solve the same problem before inventing a pattern.

    line 32
  7. Distinctive:

    Use proven references when they exist.

    line 33
  8. Very specific:

    Read memory/channels/{channel-name}.md for prior design decisions.

    line 41
  9. Distinctive:

    If memory says Aaron rejected a pattern, don't repeat it.

    line 42
  10. Distinctive:

    If a project brain file is linked from channel memory, read that too.

    line 43
  11. Distinctive:

    If the foundation is wrong, no polish fixes it.

    line 52
  12. Distinctive:

    Read only what the task needs.

    line 56
  13. Distinctive:

    Read the relevant reference files based on what you're building.

    line 65
  14. Distinctive:

    If in doubt, at minimum read spacing + anti-patterns.

    line 70
  15. Distinctive:

    Run this EVERY TIME before presenting work to Aaron.

    line 73
  16. Distinctive:

    After Aaron gives design feedback, capture it.

    line 118
  17. Very specific:

    Add redirects to references/anti-patterns.md or the relevant reference file.

    line 119
  18. Distinctive:

    Add project-specific decisions to channel memory.

    line 120

“Common” is measured: kept by at least 6 in 10 of the 121 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Design Review Skill

Core Pack — Always Active

This is a core skill. Apply it on ALL visual and frontend work, no exceptions. You do not need permission or a specific trigger to use this.

When to Use

  • Before presenting ANY visual or UX work.
  • Treat this as a quality gate, not optional polish.
  • Sub-agents doing design/frontend work MUST run this before announcing completion.

Pre-Work: Read Before Building

1. Read the project's guidelines

  • Read guidelines.md or equivalent design system doc first if it exists.
  • Follow the project's existing components, tokens, and patterns before inventing anything.
  • If no formal guidelines exist, inspect the existing product and match its logic.

2. Research before designing

  • Check how similar tools solve the same problem before inventing a pattern.
  • Use proven references when they exist.
  • Quality bar references:
    • UX Tools — editorial restraint, typography, calm hierarchy
    • Inflight by Ridd — motion, depth, data viz polish
    • Linear — dense information, excellent hierarchy, no noise
    • Vercel dashboard — spacing, typography, dark mode discipline

3. Check design memory

  • Read memory/channels/{channel-name}.md for prior design decisions.
  • If memory says Aaron rejected a pattern, don't repeat it.
  • If a project brain file is linked from channel memory, read that too.

Aaron's Core Principles

  • Restraint IS the design.
  • Spacing is the #1 tell.
  • Typography hierarchy > color for information architecture.
  • Match references at pixel level before adding your own ideas.
  • Existing patterns > new patterns.
  • Interactive elements should feel polished, not dead.
  • If the foundation is wrong, no polish fixes it.
  • Good design is centripetal, not centrifugal.

Reference Files

Read only what the task needs. Keep this SKILL lean, load detail on demand:

  • references/typography.md — hierarchy, scale, pairing, measure
  • references/color.md — restrained palettes, tinted neutrals, contrast, OKLCH
  • references/spacing.md — spacing system, rhythm, grouping, layout density
  • references/motion.md — timing, easing, reduced motion, interactive feel
  • references/anti-patterns.md — patterns Aaron will clock instantly and reject

For sub-agents

  • Read the relevant reference files based on what you're building.
  • New layout or dashboard? Read spacing + anti-patterns.
  • Type-heavy screen? Read typography + spacing.
  • Color or theming work? Read color + anti-patterns.
  • Interactive polish? Read motion + anti-patterns.
  • If in doubt, at minimum read spacing + anti-patterns.

Pre-Flight Checklist

Run this EVERY TIME before presenting work to Aaron.

Step 1: Visual verification

  • Take a screenshot of the rendered result.
  • Compare side-by-side with the reference if one exists.
  • Check the target viewport, not an arbitrary devtools width.

Step 2: Design audit

  • Spacing check — enough breathing room? Default to more.
  • Color check — did you add color that wasn't necessary?
  • Typography check — is hierarchy clear without leaning on color?
  • Pattern check — are you using the project's existing components?
  • Interaction check — hover, focus, active states exist and feel intentional.
  • Integrity check — no placeholders, dead states, broken assets, or missing data handling.

Step 3: Honesty check

  • Is it actually done?
  • Does it meet the brief, not an adjacent brief?
  • Would you be proud to show this to Aaron cold?

Step 4: Run verification scripts

if you have access to the scripts directory, run these before presenting:

# check for common agent anti-patterns
python3 skills/design-review/scripts/anti-pattern-check.py <your-file.tsx>

# verify loading, empty, and error states exist
python3 skills/design-review/scripts/state-check.py <your-file.tsx>

# check semantic HTML, aria labels, alt text, heading hierarchy
python3 skills/design-review/scripts/accessibility-check.py <your-file.tsx>

fix any warnings before presenting. these are the cheapest quality checks — they catch the obvious stuff so the human review can focus on judgment calls.

for CI integration, copy ci/design-eval.py and ci/design-eval.yml into your project to run all three checks on every PR.

Step 5: Present with evidence

  • Screenshot of the result
  • What you referenced
  • Known gaps or uncertainties
  • Link to live/deployed version if applicable

Updating This Skill

  • After Aaron gives design feedback, capture it.
  • Add redirects to references/anti-patterns.md or the relevant reference file.
  • Add project-specific decisions to channel memory.
  • Goal: don't get the same design feedback twice.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free