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 skills add arcasilesgroup/ai-engineering --skill ai-prototypegit clone --depth 1 https://github.com/arcasilesgroup/ai-engineeringWrote 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/skills/arcasilesgroup/ai-engineering/ai-prototype)<a href="https://agentmods.dev/skills/arcasilesgroup/ai-engineering/ai-prototype"><img src="https://agentmods.dev/badge/skills/arcasilesgroup/ai-engineering/ai-prototype/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/skills/arcasilesgroup/ai-engineering/ai-prototype"><img src="https://agentmods.dev/badge/skills/arcasilesgroup/ai-engineering/ai-prototype.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.00066 | $0.01480 |
| Opus 5.5 | $0.00026 | $0.00592 |
| Sonnet 5.5 | $0.00013 | $0.00296 |
| Haiku 4.5 | $0.00007 | $0.00148 |
Grade A, and why
ai-prototype 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 19d 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 — 79 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Prototype
Build a static HTML prototype of the UI the user asked for. It's for looking at and clicking through, not production code.
If you're running as a subagent (for example, launched by /ai-orchestrator), you can't launch subagents. Do the steps marked "subagent" yourself, skip open, and return only the file path and your assumptions.
1. Gather the design directions
Use these sources, highest priority first:
- The request itself: layout, tone, palette, density, references, anything the user said about the look.
- Project design sources, if they exist:
.ai-engineering/DESIGN.md, and the global styles/tokens file named in the Project config section ofAGENTS.md(colors, fonts, radii). Use them so the prototype looks like the real app. - Domain: Project config → Domain and Roles, plus
.ai-engineering/PRD.html. Make the fake data realistic for that domain: real-looking names, entities, dates, amounts and statuses. Role-dependent UI follows the roles listed there.
If the request doesn't say which screen or flow it wants, ask one short question. Missing style directions are not a reason to ask: fall back to the project tokens, and if there are none, use a clean, neutral, dense app UI.
Gather sources 2 and 3 with an Explore subagent, not by reading the files yourself. Ask it to return a compact brief with:
- Design tokens: the colors, fonts, radii and spacing from
.ai-engineering/DESIGN.mdand the global styles file, as exact values. - What the matching page has today: if a live page already exists for this screen, list its sections, components and copy (Project config → Pages and Components).
- Data fields: the fields the API really returns for this screen (Project config → Shared types and API routes), so the fake data has the right shape.
The brief keeps the raw file dumps out of your context.
2. Build
- Output: one file,
.ai-engineering/workflow/prototypes/NNN-<kebab-name>.html.NNNis the next free three-digit number in that folder (001,002, …), so several prototypes sort. Not in the app source, not at the repo root, not in another folder. Put all CSS and JS inline. Allowed external resources: Tailwind via<script src="https://cdn.tailwindcss.com"></script>and Google Fonts. Nothing else. - Scope: only the screens or states the user asked for. For a flow, put the steps in one file and switch between them with JS. Don't use extra pages.
- Interactivity: make the key interactions work: tabs, modals, form validation messages, filters over the fake data, and status changes. Use plain JS and no framework.
- States: show the empty, loading, and error states wherever the UI would really have them. Each data state must be reachable through a
?state=<name>URL parameter (e.g.?state=empty,?state=error), so review tools can open it directly. A visible switcher in the corner is optional. - Labels are a contract: use the exact field labels and button text the real page should have.
/ai-review-uidrives the prototype and the live page with the same steps by label, so if the text differs, the comparison fails. - Regions: wrap each part of the screen in an element with
data-region="<name>"(e.g.page-header,summary,edit-form). Under/ai-orchestrator, use the region names from the checkpoints'ui.scope. - State scenario: also write
.ai-engineering/workflow/prototypes/NNN-<kebab-name>.states.jsonwith the same number and name as the HTML. It lists every state the prototype shows and how to reach it. Include theregionslist, and give each state theregionsit exercises. Include the default, filled, validation-error and submitted states for forms, open dialogs, applied filters, and the?state=data states. The format is inai-review-uistep 3. It lives in.ai-engineering/workflow/prototypes/beside its HTML. - Responsive: the layout must work from 375px up to desktop width, with no horizontal scroll.
- Accessibility basics: semantic elements, labels on inputs, visible focus, and sufficient contrast.
- Declare colors, radii, and fonts once as CSS variables in
:root, so a direction change means a one-place edit.
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.
- 19d ago First seen · 79 lines · 66 tokens per session scan A ffdd61118dd7
ai-prototype is a skill published in the GitHub repository arcasilesgroup/ai-engineering (61 stars, last pushed 2d ago), licensed Apache-2.0. It adds 66 tokens to every session and 1,480 once invoked, about $0.0003 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-09-27.
Other skills, from other repositories
review
WCAG 2.2 AA curated accessibility review — distinguishes automatically detectable, browser-assisted, and manual/human-judgment findings with evidence citations and SC mapping. Composes with design-assessment/design-improvement/frontend-design-review.
web-design-guidelines
Review UI code for Web Interface Guidelines compliance. Use when asked to "review my UI", "check accessibility", "audit design", "review UX", or "check my site against best practices".
ui-ux-design
Create production-grade frontend interfaces with strong UX and visual craft. Use when building web components, pages, dashboards, forms, landing pages, modals, or any UI. Use when user says 'build a form', 'create a dashboard', 'design a component', 'make a landing page', or asks for UI/UX work. Use even when the user…
frontend-design-review
Review and create distinctive, production-grade frontend interfaces with high design quality and design system compliance. Evaluates using three pillars: frictionless insight-to-action, quality craft, and trustworthy building. USE FOR: PR reviews, design reviews, accessibility audits, design system compliance checks…
visual-artifact-qa
Visual output that passes static checks can still fail to render.
frontend-design
Use this skill when building UI components, designing frontend architecture, implementing styling systems, optimizing performance, ensuring accessibility, or creating production-grade interfaces. Trigger on keywords: frontend, component, UI, styling, React, Next.js, Angular, Tailwind, CSS, responsive, accessibility…