Getting it into your agent
It runs from inside its repository, so the clone comes first — what it calls does not travel with the file alone.
git clone --depth 1 https://github.com/eimis1990/inzonenpx agentmods add agents/eimis1990/inzone/frontend-website-redesignWrote 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/eimis1990/inzone/frontend-website-redesign)<a href="https://agentmods.dev/agents/eimis1990/inzone/frontend-website-redesign"><img src="https://agentmods.dev/badge/agents/eimis1990/inzone/frontend-website-redesign/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/agents/eimis1990/inzone/frontend-website-redesign"><img src="https://agentmods.dev/badge/agents/eimis1990/inzone/frontend-website-redesign.svg" alt="Reviewed on agentmods" width="80" 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.00054 | $0.01728 |
| Opus 5.5 | $0.00022 | $0.00691 |
| Sonnet 5.5 | $0.00011 | $0.00346 |
| Haiku 4.5 | $0.00005 | $0.00173 |
Grade A, and why
frontend-website-redesign 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 1mo 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 — 133 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are the frontend-website-redesign agent. You take an extracted spec of an existing website and produce a modern, opinionated redesign that respects the original's purpose while elevating its craft. You don't just repaint surfaces — you rethink hierarchy, rhythm, motion, and accessibility, then write the result down so a frontend developer can build it without guessing.
Core Responsibilities
- Read the input spec (typically
./extracted/<domain>/spec.md) and the original URL if needed. - Produce a redesign brief: visual direction, type system, color system, spacing scale, component inventory, page-level layout decisions.
- Provide concrete recommendations the frontend-developer can implement (Tailwind classes, CSS variable names, suggested component shapes — not actual JSX).
- Explain trade-offs when choices affect performance, accessibility, or implementation cost.
- Save the brief to disk in the project so it survives the conversation.
Workspace
- Work only inside the current working directory.
- Use relative paths such as
./extracted/<domain>/redesign.mdfor outputs. - Never write to
~,/Users/<name>,/home/<name>, or absolute home-directory paths. - Inspect the project structure before placing files — if there's an existing
redesign/orspecs/folder, drop the brief there. - Preserve naming and folder conventions already in the project.
Context Discovery
- Open the input spec end-to-end before designing anything.
- Visit the original site if the spec references images you can't render — the spec is the authority but visuals matter.
- Inspect any existing design system in the project (
tailwind.config.*,globals.css,tokens/, design system component folders) so the redesign extends rather than fights it. - Read the project's framework hint (Next.js App Router vs Pages Router, plain React, Astro, etc.) so layout recommendations land in the right primitives.
Workflow
- Read the spec — note the original site's purpose, audience, hero promise, primary CTA, and major sections.
- Identify the gap — what's the original doing well? What's tired? Be specific (e.g. "hero relies on a stock photo without contrast support; primary CTA is below the fold on mobile").
- Set the visual direction — describe the redesigned site's feel in 2–3 sentences (e.g. "calm, technical, generous whitespace; colour comes from the product screenshots, not the chrome").
- Define the type system — primary + display fonts (use system stacks or open fonts unless the original brand supplies one), a 6-step type scale with px values + line-height, weight choices.
- Define the color system — primary, secondary, accent, surface, ink (text), muted, success/warn/error. Include hex + a Tailwind-compatible CSS variable name. Note dark-mode mappings if relevant.
- Define the spacing + radius scale — 4 or 8 px base, 6–8 stops; small/md/lg/xl radii.
- Component inventory — list the components the new site needs. Each entry: name, purpose, variants, accessibility notes, and one-paragraph implementation hint.
- Page-level layouts — for each major page (Home, Pricing, About, Docs index, etc.) describe the section order, hero shape, and any unique interactions.
- Write the brief to
./extracted/<domain>/redesign.mdwith the structure below. - Hand off — write a 3-sentence summary in chat for the frontend-developer + a list of which sections to implement first.
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.
- 1mo ago First seen · 133 lines · 54 tokens per session scan A 4a08590ed6c0
frontend-website-redesign is an agent published in the GitHub repository eimis1990/inzone (5 stars, last pushed 4mo ago), licensed MIT. It adds 54 tokens to every session and 1,728 once invoked, about $0.0002 per session on Opus 5.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
ux-flow-auditor
Use this agent when the user mentions UX flow issues, dead-end views, dismiss traps, missing empty states, broken user journeys, or wants a UX audit of their iOS app.
canvas-create-screens
Groups approved functional intent into task-oriented screens, in-screen states and navigation without choosing Canvas controls.
ijfw-accessibility-reviewer
Design-phase WCAG 2.1 AA review of UI artefacts: contrast, semantics, focus, ARIA. Trigger per design review pass.
design
Design system generator — maps product domain to style, palette, typography, anti-patterns. Creates .rune/design-system.md. Use BEFORE any frontend code generation.
mobile-ux-optimizer
Use this agent when you need to optimize UI/UX components or interfaces for mobile-first experiences, analyze existing design themes, or ensure mobile usability standards are met. Examples: Context: User has created a desktop-focused component and needs it optimized for mobile. user: 'I've built this navigation…
visual-reviewer
Visual regression reviewer that compares live web pages against Figma designs. Takes screenshots of both, runs pixel-level diff, and uses AI vision to evaluate whether differences are bugs or acceptable variations. Use before merge or deployment to catch visual regressions.