Review design
Stack-agnostic agentic-programming workflow skills + documentation scaffold
npx -y skills add gtrabanco/agentic-workflow --skill review-designAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 19 stars19 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Internal 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 has a UI and the change touches it. Findings only; never edits code.
The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
2.5 KB, as published. Nobody here has run it
Review Design (internal)
Composed by review-change / product-audit within their conversation — on any
agent, follow this file inline as the routed step. Findings only; never edits,
never refactors.
Scope
The diff or path/glob the caller passes; default the current change vs the default branch. State the scope at the top of the returned table.
Checklist (evaluate EVERY item — none is optional; n/a must be stated)
✓ Read the project's design doc first (e.g. docs/frontend/DESIGN.md) — cite the rule for every finding ✓ Changed components reuse the design system (no one-off styles/colors/spacing duplicating existing tokens or components) ✓ Every new/changed view handles ALL states: loading, empty, error, success (cite each) ✓ Responsive behavior stated and honored at the project's breakpoints (n/a if the platform has none) ✓ No hardcoded user-facing strings where the project declares i18n (cite the i18n doc) ✓ Visual hierarchy: primary action distinguishable, one primary action per view ✓ Consistency with sibling screens (same patterns for the same interactions — cite the diverging sibling) ✓ Destructive actions require confirmation and are visually distinct ✓ Feedback on every user action (submit, save, fail) — no silent operations
Return exactly
REVIEW DESIGN — scope: <scope>
| # | Finding | Sev | Evidence | Suggested fix |
|---|---------|-----|----------|---------------|
| 1 | <what> | critical|major|minor | <file:line> | <smallest action> |
Checklist: <n> evaluated, <n> pass, <n> findings, <n> n/a (<which + why>)
Summary: <1-2 sentences>
Decision: PASS | FAIL
FAIL if any critical or major finding is open; PASS otherwise. Minor findings never block — they route to the caller's triage step.
Done when
- Every checklist item was evaluated with evidence (file:line or command output) or explicitly marked n/a with the reason.
- The fixed-format block above is returned — nothing more, nothing less — and no code was changed.