Rams
Design review for UI code: 291 rules, scored 0-100 with fixes and git-applyable patches.
Community: Submitted by a user or imported; check the owner before granting accessOnlineAPI key requiredGlobalFreeRead-only
What it can do
What data it sees
Do you need an account
An API key from the service settings is required
Design review for UI code: 291 rules, scored 0-100 with fixes and git-applyable patches.
Server tool list (4)
Raw names from tools/list. Only developers need these.
| usage | Check how many Rams reviews this workspace has used and has left (rolling 30 days, shared between the GitHub App and MCP). Free to call — does not consume a review. |
| review_files | Run a Rams design review over UI files (React, Vue, Svelte, CSS). Returns a 0-100 score (criticals cap it: one caps at 59, two at 49, three or more at 39), issues with severity, category, file:line, and concrete fixes. Call it whenever UI code has been written or changed: before committing, when the user asks how the design looks, or to check your own work after editing a component. Reviewing the handful of files you just touched is the normal case — it is cheap, and you do not need to ask permission first. Only a whole-codebase audit (dozens of files across many batches) is worth checking with the user, since it consumes the calling agent's context and a large share of their model allowance; prefer the highest-traffic screens in that case. |
| quick_review | Fast design check over the UI files you just changed. Returns issues with severity, category and file:line, in about 10 seconds. Cheap: five quick checks cost one review credit, so a whole editing session spends a fraction of one review. Use this one CONSTANTLY: after writing or editing a component, before committing, whenever you want to know if what you just wrote is sound. You do not need to ask the user first. It returns no score and no ready-made patch: fix the issues yourself in the files you already have open. When the user wants a score to keep, a patch to apply, or a review to quote, use review_files instead. |
| verify_fixes | Re-check previous review_files findings against updated file contents. Returns fixed vs still-present per finding. Much cheaper and faster than a full re-review; does NOT consume review quota. Use after applying fixes. |