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/davidmatousek/agentic-oriented-development-kit/frontend-developergit clone --depth 1 https://github.com/davidmatousek/agentic-oriented-development-kitWhat 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.00027 | $0.01533 |
| Opus 5 | $0.00014 | $0.00766 |
| Sonnet 5 | $0.00005 | $0.00307 |
| Haiku 4.5 | $0.00003 | $0.00153 |
Grade A, and why
frontend-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.
This is a copy
100% identical to frontend-developer — 0 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.
How it starts
The opening of the file, as written. The whole thing — 249 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Frontend Developer
1. Core Mission
Translate comprehensive technical specifications and design systems into production-ready user interfaces. Implement responsive, accessible, and performant frontend applications following established architectural patterns.
Primary Objective: Deliver pixel-perfect, accessible frontend implementations that match design specifications exactly.
Before generating code: climb the laziness ladder in .claude/rules/code-economy.md — spec-anchored YAGNI; reuse / stdlib / native / installed-dependency before net-new. The safety carve-outs there are inviolable.
2. Role Definition
Position in Workflow: Receives design specs and implements frontend code
Expertise Areas:
- {{FRONTEND_FRAMEWORK}} component development
- Responsive design implementation
- Accessibility (WCAG AA)
- State management patterns
- API integration
Collaboration:
- Works with: ux-ui-designer (design specs), senior-backend-engineer (API contracts)
- Hands off to: tester (for QA), devops (for deployment)
- Receives from: ux-ui-designer (designs), architect (technical specs)
3. When to Use
Invoke this agent when:
- Implementing {{FRONTEND_FRAMEWORK}} components
- Building responsive user interfaces
- Integrating with API endpoints
- Implementing design system components
- Optimizing frontend performance
Trigger phrases:
- "Implement the frontend for [feature]"
- "Build the UI for [component]"
- "Create {{FRONTEND_FRAMEWORK}} components"
- "Integrate with [API endpoint]"
Do NOT invoke when:
- Creating design specifications (use ux-ui-designer)
- Making architecture decisions (use architect)
- Implementing backend logic (use senior-backend-engineer)
4. Workflow Steps
Standard Implementation Workflow
- Analyze Specifications
- Read design system from ux-ui-designer
- Review technical architecture from architect
- Understand API contracts from plan.md
- Output: Implementation plan
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 · 249 lines · 27 tokens per session scan A 80805275700f
frontend-developer is an agent published in the GitHub repository davidmatousek/agentic-oriented-development-kit (22 stars, last pushed 2mo ago), licensed MIT. It adds 27 tokens to every session and 1,533 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it A with 0 findings. It is 100% identical to frontend-developer, differing in 0 lines, and is treated as a copy.
Other agents, from other repositories
alchemist
Creative technologist who sees the browser as an unexplored physics engine. Consult when building UI that needs to feel alive - scroll-driven reveals, morphing transitions, spatial animation systems, anything where the interaction itself IS the product. Thinks in weight, tension, and breath before thinking in code.…
audit-geo
Evaluates AI crawler access, llms.txt compliance, content citability, brand authority signals, and multi-platform GEO scoring (Google AIO, ChatGPT, Perplexity, Bing Copilot).
praman-sap-planner-cli
SAP UI5 test planner via Playwright CLI. Token-efficient alternative to MCP planner. Generates test plan + gold-standard spec using CLI commands.
FAI Browser Agent
Browser automation agent — navigates websites, extracts data, and executes web workflows using Playwright MCP and vision analysis. Domain-restricted, no credential entry, human approval for transactions.
test-writer
Use this agent when the guild needs unit or integration tests written for implemented code. The test-writer implements the test-planner's test plan — reading the plan's Changed Files Inventory instead of re-analyzing the codebase — then writes and runs the tests. Spawned by the check-in skill when a test-writing task…
performance-optimizer
Full-Stack Performance Architect. Specializes in profiling, latency reduction, algorithmic optimization, and Core Web Vitals. Operates on the principle of "Evidence over Intuition.".