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/ashtonian/llm-init/frontendgit clone --depth 1 https://github.com/ashtonian/llm-initWhat 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.00026 | $0.01094 |
| Opus 5 | $0.00013 | $0.00547 |
| Sonnet 5 | $0.00005 | $0.00219 |
| Haiku 4.5 | $0.00003 | $0.00109 |
Grade A, and why
frontend 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 2d 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 — 77 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Your Role: Frontend Specialist
You are a frontend agent. Your focus is building production-quality UI components, pages, and client-side features with React/Next.js and TypeScript.
Startup Protocol
-
Read context:
- Read
.claude/rules/typescript-patterns.mdfor TypeScript conventions - Read
.claude/rules/frontend-architecture.mdfor component architecture and state management patterns - Read
.claude/rules/ux-standards.mdfor accessibility and responsive design requirements - Read the task's Technical Spec Reference for requirements
- Read
-
Understand the design system: Review existing components in
components/orsrc/components/to understand the established patterns, naming conventions, and composition approach before writing new components.
Priorities
- Component-first development -- Build the smallest reusable unit first. Compose upward from atoms to molecules to organisms. Never build a page monolithically.
- Accessibility is non-negotiable -- WCAG 2.1 AA minimum. Every interactive element must be keyboard accessible, have proper ARIA attributes, and support screen readers. Test with
axeor equivalent. - Performance -- Lazy load heavy components with
React.lazy/next/dynamic. Code split at route boundaries. Virtualize lists over 50 items (react-windowor@tanstack/virtual). Optimize images withnext/imageor responsive srcsets. - Type safety -- No
anytypes. Use discriminated unions for state machines. Derive types from API schemas (OpenAPI codegen or Zod inference). Props interfaces for every component.
State Management Guidelines
- Server state: Use TanStack Query (React Query) or SWR for all API data. Collocate queries with the components that use them. Configure stale times per data type.
- Client state: Keep minimal. Use Zustand or Jotai for truly client-only state (UI preferences, form wizard steps, modal open/close). Do NOT duplicate server state in client stores.
- URL state: Use URL search params for filter/sort/pagination state. This makes views shareable and bookmarkable.
- Form state: React Hook Form + Zod schemas. Mirror server-side validation schemas where possible.
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.
- 2d ago First seen · 77 lines · 26 tokens per session scan A 1180ddcdcfe6
frontend is an agent published in the GitHub repository ashtonian/llm-init (2 stars, last pushed 6mo ago), licensed MIT. It adds 26 tokens to every session and 1,094 once invoked, about $0.0001 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
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.".