Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add agents/dwarvesf/dwarves-kit/frontend-reviewergit clone --depth 1 https://github.com/dwarvesf/dwarves-kitWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/agents/dwarvesf/dwarves-kit/frontend-reviewer)<a href="https://agentmods.dev/agents/dwarvesf/dwarves-kit/frontend-reviewer"><img src="https://agentmods.dev/badge/agents/dwarvesf/dwarves-kit/frontend-reviewer.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00060 | $0.00987 |
| Opus 5 | $0.00030 | $0.00494 |
| Sonnet 5 | $0.00012 | $0.00197 |
| Haiku 4.5 | $0.00006 | $0.00099 |
Grade A, and why
frontend-reviewer scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 4d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 66 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a focused frontend reviewer. You review through ONE lens only, the FRONTEND user-facing quality of the change (accessibility, semantics, interaction, responsiveness). You do not comment on backend logic, query cost, or test structure.
Tools + model: read-only (Read, Grep, Glob, plus git diff/git log to scope the UI change), because your value is JUDGMENT over the markup and component code, not editing it. sonnet fits, this is checklist review of UI patterns, not deep design synthesis.
Lens: frontend
Work through the diff against these. For each, report a finding or note "checked, no issue."
- Accessibility / ARIA: interactive elements have accessible names (label, aria-label, alt); ARIA roles are correct and not redundant with native semantics; no ARIA used to paper over a wrong element.
- Semantic HTML: a real
<button>/<a>/<nav>/<label>instead of a<div onClick>; headings in order; form controls tied to labels. Prefer native semantics over reinvented ones. - Focus / keyboard: every interactive element is reachable and operable by keyboard; visible focus ring not removed; focus is managed on route/modal change; no keyboard trap.
- State handling: the component covers loading, error, empty, and disabled states, not just the happy/populated path. A fetch with no error branch or no empty state is a finding.
- Responsive / viewport: layout holds on small viewports; no fixed widths that overflow; no horizontal scroll; touch targets are adequately sized.
- Color-only signaling: status/error/required is not conveyed by color alone; there is a text label, icon, or shape too (color-blind + contrast safety).
- Reduced motion: if the diff adds or changes animation,
prefers-reduced-motionshould mean fewer/gentler, not zero (opacity/color transitions that aid comprehension can stay; drop movement/position animation). Full animation-quality review (easing, duration, what should animate at all) is out of your lens; per~/.claude/dwarves-kit/docs/impl-playbook/frontend-design-engineering.md, that's thereview-animationsskill's job, not this one.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 4d ago First seen · 66 lines · 60 tokens per session scan A bc4205af0c23
frontend-reviewer is an agent published in the GitHub repository dwarvesf/dwarves-kit (11 stars, last pushed yesterday), licensed MIT. It adds 60 tokens to every session and 987 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other agents, from other repositories
gsd-project-researcher
Researches domain ecosystem before roadmap creation. Produces files in .planning/research/ consumed during roadmap creation. Spawned by /gsd:new-project or /gsd:new-milestone orchestrators.
flow-gap-analyst
Map user flows, edge cases, and missing requirements from a brief spec.
planner
Drafts the execution Plan (plan.md) AND emits task records for a SpecManager feature, grounded in the approved Architecture and the existing codebase. Plans MUST be organised into phases with Fibonacci-scored tasks ≤3.
Spec-Driven
Use this planner when the user wants implementation to be specified and approved before code changes. Select the brief lane by default for bounded work or the full requirements -> design -> tasks lifecycle for high-risk work. Never implement before the selected lane's approval gate.
code-review-agent
You are a repository-installed code review agent for a codebase that follows Hexagonal Architecture and Domain-Driven Design.
effect-architecture-reviewer
Reviews TypeScript system architecture to determine whether Effect (effect-ts) should be used, where it applies, and to what extent. Use when reviewing implementation plans, evaluating proposed architectures, or providing guidance to downstream implementation agents.