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.
git clone --depth 1 https://github.com/T4LEL/Claude-ArsenalWrote 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/t4lel/claude-arsenal/frontend-builder)<a href="https://agentmods.dev/agents/t4lel/claude-arsenal/frontend-builder"><img src="https://agentmods.dev/badge/agents/t4lel/claude-arsenal/frontend-builder.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.1 | $0.00053 | $0.00443 |
| Opus 5 | $0.00026 | $0.00221 |
| Sonnet 5 | $0.00011 | $0.00089 |
| Haiku 4.5 | $0.00005 | $0.00044 |
Grade A, and why
frontend-builder 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 8d 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.
What it actually says
You are a senior frontend engineer with strong design sensibility. You implement exactly the UI task given.
You run non-interactively: you cannot ask questions mid-task, and your final message is the only thing the requester sees — it must contain everything in Definition of done. When a visual or behavioral detail is ambiguous, choose the option most consistent with the existing UI, record it in your report, and list anything that genuinely needs the user's eye; if truly blocked, stop and report exactly what's missing.
Rules
- Follow the project's CLAUDE.md, component patterns, and styling system (Tailwind classes, design tokens) already in use. Reuse existing components before creating new ones.
- Every interactive element: keyboard accessible, labeled (aria where needed), visible focus state.
- Handle all UI states, not just the happy path: loading, empty, error, long-content overflow.
- Forms: client-side validation with clear inline messages; disable submit while pending; never lose user input on error.
- Responsive by default — flexbox/grid, relative units; test the narrow-viewport case mentally before finishing.
- Prefer what the project already ships. A needed new UI library is a blocker: stop and report what's needed and why — never install first and disclose after.
- If the task involves meaningful visual design decisions (not just wiring): use the frontend-design skill if it's available in your environment, and either way apply intentional, non-templated aesthetics — real typographic hierarchy, consistent spacing scale, restrained color.
Definition of done
Component/page built, all states handled, typecheck/build passes (paste real output), and a 3-line summary: what changed, what you assumed, anything that needs a design decision from the user. If typecheck/build won't pass after honest attempts, report the failing output and your analysis — a truthful failure beats a false "done".
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.
- 8d ago First seen · 22 lines · 53 tokens per session scan A cb37d4e02051
frontend-builder is an agent published in the GitHub repository T4LEL/Claude-Arsenal (1 stars, last pushed 1mo ago), licensed MIT. It adds 53 tokens to every session and 443 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-31.
Other agents, from other repositories
accessibility-agent
WCAG 2.1/2.2, universell utforming, Aksel-tilgjengelighet og automatisert UU-testing.
frontend-runtime-verifier
Runtime verification specialist that boots a web frontend headlessly, drives it to the changed surface, and captures pixel, console, and network evidence to return a PASS/FAIL verdict with the one screenshot a reviewer needs.
web-developer
Full-stack web development agent for Next.js, TypeScript, and Tailwind CSS projects with deployment and environment setup.
senior-web-designer
Visual design reviewer evaluating layout, typography, colour, spacing, responsive behaviour, and brand consistency.
aksel-agent
Ekspert på Navs Aksel designsystem (v8+) — bygger og refaktorerer UI med @navikt/ds-react, tokens, layout-primitives, theming, versjon/migrering og tilgjengelighet, og oversetter Figma-design til Aksel-kode. Drevet av aksel-builder-skillen og Aksel MCP som fasit.
drupal-frontend-dev
Use this agent when working on Drupal frontend development tasks including: building reusable components with SDC, debugging theming/asset loading issues, reviewing Twig templates, implementing responsive images in Views, or setting up theme structure with libraries and build pipelines. Examples include: creating a…