review-design
installsforks
How to install review-design?
gtrabanco/agentic-workflow/review-design
$npx -y skills add gtrabanco/agentic-workflow --skill review-designInternal UI/UX design review pass of the agentic-workflow review pack — composed in-turn by review-change and product-audit; not a menu entry. Checks the changed UI against the project's design doc: consistency, states, responsiveness, and reuse — applies only when the project ha
SKILL.md
| 1 | # Review Design (internal) |
| 2 | |
| 3 | Composed by `review-change` / `product-audit` within their conversation — on any |
| 4 | agent, follow this file inline as the routed step. **Findings only; never edits, |
| 5 | never refactors.** |
| 6 | |
| 7 | ## Scope |
| 8 | |
| 9 | The diff or path/glob the caller passes; default the current change vs the |
| 10 | default branch. State the scope at the top of the returned table. |
| 11 | |
| 12 | ## Checklist (evaluate EVERY item — none is optional; n/a must be stated) |
| 13 | |
| 14 | ✓ Read the project's design doc first (e.g. docs/frontend/DESIGN.md) — cite the rule for every finding |
| 15 | ✓ Changed components reuse the design system (no one-off styles/colors/spacing duplicating existing tokens or components) |
| 16 | ✓ Every new/changed view handles ALL states: loading, empty, error, success (cite each) |
| 17 | ✓ Responsive behavior stated and honored at the project's breakpoints (n/a if the platform has none) |
| 18 | ✓ No hardcoded user-facing strings where the project declares i18n (cite the i18n doc) |
| 19 | ✓ Visual hierarchy: primary action distinguishable, one primary action per view |
| 20 | ✓ Consistency with sibling screens (same patterns for the same interactions — cite the diverging sibling) |
| 21 | ✓ Destructive actions require confirmation and are visually distinct |
| 22 | ✓ Feedback on every user action (submit, save, fail) — no silent operations |
| 23 | |
| 24 | ## Return exactly |
| 25 | |
| 26 | ``` |
| 27 | REVIEW DESIGN — scope: <scope> |
| 28 | |
| 29 | | # | Finding | Sev | Evidence | Suggested fix | |
| 30 | |---|---------|-----|----------|---------------| |
| 31 | | 1 | <what> | critical|major|minor | <file:line> | <smallest action> | |
| 32 | |
| 33 | Checklist: <n> evaluated, <n> pass, <n> findings, <n> n/a (<which + why>) |
| 34 | Summary: <1-2 sentences> |
| 35 | Decision: PASS | FAIL |
| 36 | ``` |
| 37 | |
| 38 | FAIL if any critical or major finding is open; PASS otherwise. Minor findings |
| 39 | never block — they route to the caller's triage step. |
| 40 | |
| 41 | ## Done when |
| 42 | |
| 43 | - Every checklist item was evaluated with evidence (file:line or command output) |
| 44 | or explicitly marked n/a with the reason. |
| 45 | - The fixed-format block above is returned — nothing more, nothing less — and |
| 46 | no code was changed. |
People who liked this also viewed
6 picksType
- requesting-code-reviewUse when completing tasks, implementing major features, or before merging to verify work meets requirementsSkillsJul 2026
- code-reviewSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- receiving-code-reviewUse when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performativeSkillsJul 2026
- baoyu-format-markdownFormats plain text or markdown files with frontmatter, titles, summaries, headings, bold, lists, and code blocks. Use when user asks to "format markdown", "beautify article", "add formatting", or imprSkillsJul 2026
- code-review-excellenceMaster effective code review practices to provide constructive feedback, catch bugs early, and foster knowledge sharing while maintaining team morale. Use when reviewing pull requests, establishing reSkillsJul 2026
- code-review-and-qualityConducts multi-axis code review. Use before merging any change. Use when reviewing code written by yourself, another agent, or a human. Use when you need to assess code quality across multiple dimensiSkillsJul 2026
