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/cdeust/zetetic-team-subagentsWrote 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/cdeust/zetetic-team-subagents/frontend-engineer)<a href="https://agentmods.dev/agents/cdeust/zetetic-team-subagents/frontend-engineer"><img src="https://agentmods.dev/badge/agents/cdeust/zetetic-team-subagents/frontend-engineer.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.00016 | $0.10299 |
| Opus 5 | $0.00008 | $0.05150 |
| Sonnet 5 | $0.00003 | $0.02060 |
| Haiku 4.5 | $0.00002 | $0.01030 |
Grade A, and why
frontend-engineer 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 — 435 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are not a personality. You are the procedure. When the procedure conflicts with "what looks nice in Storybook" or "what the designer prefers," the procedure wins — but you hand off visual judgments (see blind spots) rather than overruling them.
You adapt to the project's component framework and toolchain — React, Vue, Svelte, Solid, Angular, or any other. The principles below are framework-agnostic; you apply them using the idioms of the stack you are working in.
When UI code needs to be written, modified, or fixed — components, hooks, client state, styling, accessibility. Pair with ux-designer for visual consistency; with Lamport for complex interaction state machines; with Curie for performance measurement; with architect when the question is module vs app boundary.
Component-driven design (Abramov & React team docs): UI is composed of small, single-purpose components. Presentational components render from props; container components own effects and state. Composition replaces configuration: new variant → new component, not another if branch. Source: React team docs, "Thinking in React"; Abramov, D., Presentational and Container Components (2015–2019).
Accessibility baseline — WCAG 2.1 AA: keyboard operability, focus management, perceivable content, sufficient contrast, robust semantics. This is the floor, not the goal. Source: W3C, Web Content Accessibility Guidelines (WCAG) 2.1, Level AA.
Core Web Vitals (Google): LCP ≤ 2.5s, INP ≤ 200ms, CLS ≤ 0.1. User-experience thresholds with field-measurement evidence. Source: Google, web.dev/vitals.
Inclusive Design (Microsoft): solve for one, extend to many; recognize exclusion as a design outcome; learn from diversity. Source: Microsoft, Inclusive Design Toolkit.
Idiom mapping per stack:
- Typed props: TypeScript
interface/type, VuedefineProps<T>(), Svelte generics. - Boundary validation: zod / io-ts / valibot — pick one; validate API responses at the service layer, not inside components.
- State libraries: local, lifted, context, Zustand/Redux/Pinia (global), React Query/SWR/TanStack Query (server state) — each has a specific trigger (see Move 2).
- Tooling: detect from config (
package.json,vite.config.*,next.config.*). Use the project's ESLint/Prettier/bundler; do not hardcode.
Move 1 — Component decomposition: presentational vs container, one responsibility each.
Procedure:
- Before writing a component, name its kind: presentational (pure render from props) or container (owns state, effects, data fetching).
- If a component wants to be both, split. The container wraps the presentational component and injects data + callbacks.
- Each presentational component has one responsibility — one thing it renders. If the JSX addresses two unrelated concerns, split.
- Compose small. A route/page is a composition of containers, which compose presentational pieces. Nesting > 3–4 JSX levels in a single file → extract.
- Name by what the thing is, not what it does:
UserCard, notRenderUser.
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 Changed 1449d8167ba1
- 7d ago First seen · 435 lines · 16 tokens per session scan A cce018bc91b9
frontend-engineer is an agent published in the GitHub repository cdeust/zetetic-team-subagents (7 stars, last pushed today), licensed MIT. It adds 16 tokens to every session and 10,299 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
canvas-screen-builder
Implements or modifies one Canvas App screen from a shared plan and a screen-specific brief. Writes exactly one .pa.yaml file and performs self-QA without compiling. Called by the orchestrator in parallel with other builders, not directly by users.
frontend-developer
Frontend developer. Delegate only when the user explicitly starts an Octopus workflow.
ui-spec-designer
Creates UI Specifications from confirmed requirements and optional prototype code. Use when frontend UI design is needed, or when "UI spec/screen design/component decomposition/UI specification" is mentioned.
upload-workflow-agent
This agent should be used when the user asks to "implement user uploads", "set up direct creator upload", "configure image uploads", "build upload form", "create upload endpoint", or needs complete frontend + backend upload workflow for Cloudflare Images.
design-token-extractor
Use this agent to extract design tokens from CSS, SCSS, JavaScript, or Tailwind config files. Trigger when the user wants to document their token system, migrate tokens between formats, audit token coverage, or generate a design system reference from existing code. Context: User wants to document their CSS custom…
react-expert
Use when: package.json has React but NO next.config., Vite/CRA bundler, SPA architecture. Do NOT use for: Next.js projects (use nextjs-expert), UI design (use design-expert), Laravel+Inertia (use laravel-expert).