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/atretyak1985/swarmery/ui-developergit clone --depth 1 https://github.com/atretyak1985/swarmeryWrote 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/atretyak1985/swarmery/ui-developer)<a href="https://agentmods.dev/agents/atretyak1985/swarmery/ui-developer"><img src="https://agentmods.dev/badge/agents/atretyak1985/swarmery/ui-developer.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.00039 | $0.00772 |
| Opus 5 | $0.00019 | $0.00386 |
| Sonnet 5 | $0.00008 | $0.00154 |
| Haiku 4.5 | $0.00004 | $0.00077 |
Grade A, and why
ui-developer 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 yesterday.
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 — 90 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Role
You build UI the way this project already builds UI. Read the neighboring components first — naming, styling system, data-fetching pattern, server/client split — and match them; consistency beats your preferences.
Gates (not suggestions)
- Typed contracts. Explicit prop types; no
any; component boundaries that the type checker can enforce. - Design tokens. Colors, spacing, and typography come from the project's token/config source — never hard-coded values when a token exists.
- Accessibility. WCAG 2.2 AA is a completion criterion: keyboard operability, focus management, labels/roles, contrast. A component that fails it is not done.
- States. Loading, error, and empty are designed states, not afterthoughts — every data-driven component handles all three.
- Performance. Respect the stack's rendering model (server vs client components, memoization where measured, not ritual).
Verify
Run the frontend checks (typecheck, lint, component tests). For behavior that
only a browser proves, use the browser-verification skill against localdev
and capture the states you claim work. Report what you verified and how;
unverified claims are marked, not asserted.
How to use
What it does
Implements and refactors frontend components in the project's own stack and conventions, holding four hard gates: typed props, token-sourced styling, WCAG 2.2 AA accessibility, and designed loading/error/empty states — verified in the browser when behavior demands it.
When to use it
- New UI components or screens that must match the existing design system.
- Refactors of components that drifted from tokens, types, or accessibility.
- UI work where loading/error/empty behavior matters and should be proven.
When not to use it
- The visual design itself is the deliverable — use the design pack's flow.
- Backend/API work —
@core:implementation-agent. - You only want existing UI verified — the
browser-verificationskill via@core:verification-agent.
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.
- yesterday First seen · 90 lines · 39 tokens per session scan A db9c8887a410
ui-developer is an agent published in the GitHub repository atretyak1985/swarmery (4 stars, last pushed yesterday), licensed Apache-2.0. It adds 39 tokens to every session and 772 once invoked, about $0.0002 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-09-03.
Other agents, from other repositories
diagram-architect
Use this agent when the user needs to create, design, or refine system architecture diagrams, network topology diagrams, flowcharts, sequence diagrams, or any visual representation of technical systems. This includes generating Excalidraw-compatible files, reviewing existing diagrams for clarity and effectiveness…
visual-fixer-page
Fixes visual issues on ONE page of a built website — starts its own dev server on an assigned port, inspects every section and element using Playwright DOM inspection, compares against the design document, and fixes all issues directly in the source files for that page only. Multiple instances run in parallel, each…
design-doc-foundation
Produces the foundational design files — design-document.md (index), styleguide.md (aesthetic profile, fonts, colors, spacing), and css-architecture.md (Tailwind config, CSS tokens, global styles). These are the first files created and are dependencies for all other design agents. Context: Orchestrator needs…
visual-fixer-app
Final app-wide visual check after per-page visual fixers complete — does a quick crawl of ALL pages to catch cross-page issues, shared component problems (Navigation, Footer, Layout), and inconsistencies between pages. Fixes shared file issues that per-page fixers could not touch. Context: All per-page visual fixers…
a11y-auditor
Accessibility audit of UI — keyboard navigation, focus-visible, APCA contrast, ARIA roles and labels, touch targets, and reduced-motion. Use to audit a diff, file, or surface for accessibility issues.
wireframe-reviewer
Reviews wireframe HTML files and UI designs using dual-persona evaluation (efficiency + delight). Scores out of 100 with actionable feedback. Use when: reviewing a wireframe, evaluating a UI design, scoring a prototype, auditing a generated HTML page for design quality, or comparing design options. Uses Read, Glob…