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 OpenAEC-Foundation/OpenAEC-Workspace-Composer --skill vite-agents-reviewgit clone --depth 1 https://github.com/OpenAEC-Foundation/OpenAEC-Workspace-ComposerWrote 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/openaec-foundation/openaec-workspace-composer/vite-agents-review)<a href="https://agentmods.dev/skills/openaec-foundation/openaec-workspace-composer/vite-agents-review"><img src="https://agentmods.dev/badge/skills/openaec-foundation/openaec-workspace-composer/vite-agents-review/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/openaec-foundation/openaec-workspace-composer/vite-agents-review"><img src="https://agentmods.dev/badge/skills/openaec-foundation/openaec-workspace-composer/vite-agents-review.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.00112 | $0.02960 |
| Opus 5 | $0.00056 | $0.01480 |
| Sonnet 5 | $0.00022 | $0.00592 |
| Haiku 4.5 | $0.00011 | $0.00296 |
Grade A, and why
vite-agents-review 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 12d 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 — 171 lines — stays where its author put it; the contents beside it link to each section on GitHub.
vite-agents-review
How to Use This Skill
Run every check in order. Mark each item PASS or FAIL. A single FAIL in a critical area (Security, Configuration) blocks deployment. Fix all FAILs before approving code.
1. Configuration Checks
| # | Check | Expected State | Common Failure |
|---|---|---|---|
| C-01 | defineConfig() wraps config export |
ALWAYS use defineConfig() for type safety and IDE support |
Raw object export loses autocomplete and type checking |
| C-02 | Bundler options match target version | v8: build.rolldownOptions / v6-v7: build.rollupOptions |
Using rollupOptions on v8 triggers deprecation; using rolldownOptions on v6 is invalid |
| C-03 | Transform config matches target version | v8: oxc option / v6-v7: esbuild option |
Using esbuild on v8 is deprecated; using oxc on v6 is invalid |
| C-04 | envPrefix is NOT empty string |
MUST be 'VITE_' or a non-empty custom prefix |
Setting envPrefix: '' exposes ALL environment variables to client code |
| C-05 | appType matches usage pattern |
'spa' for single-page, 'mpa' for multi-page, 'custom' for SSR/middleware |
Wrong appType causes missing HTML middleware or unwanted SPA fallback |
| C-06 | build.target is appropriate |
Use 'baseline-widely-available' (v7+/v8) or explicit browser list |
Setting 'esnext' for production breaks older browsers |
| C-07 | loadEnv() used in config, NOT import.meta.env |
ALWAYS use loadEnv(mode, root, prefix) inside config files |
import.meta.env is undefined during config resolution |
| C-08 | Conditional config uses function form | defineConfig(({ command, mode }) => ({...})) |
Forgetting command/mode parameters leads to static config for all modes |
2. Plugin Checks
| # | Check | Expected State | Common Failure |
|---|---|---|---|
| P-01 | Plugin is a factory function returning object | ALWAYS export a function, NEVER a plain object | Plain objects prevent configuration via options parameter |
| P-02 | Plugin object has name property |
ALWAYS include name string on plugin object |
Missing name makes errors/warnings untraceable |
| P-03 | config hook returns partial config or mutates |
Return object is deep-merged; mutations are applied directly | Returning a full config object overwrites user settings |
| P-04 | configResolved stores config for later hooks |
Store resolved config in closure variable | Accessing config parameter outside the hook lifecycle |
| P-05 | configureServer adds middleware correctly |
Use server.middlewares.use() for pre-middleware; return function for post-middleware |
Adding post-middleware directly instead of returning a function |
| P-06 | transformIndexHtml uses correct order property |
order: 'pre' for before HTML processing, order: 'post' (default) for after |
Using deprecated enforce property (removed in v7) |
| P-07 | handleHotUpdate returns correct type |
Return ModuleNode[] to narrow updates, [] to skip, or void for default |
Returning wrong type causes HMR failures |
| P-08 | enforce property used correctly |
'pre' runs before core plugins, 'post' runs after build plugins |
Omitting enforce when ordering matters causes transform conflicts |
| P-09 | Virtual modules use correct prefix convention | User-facing: virtual: prefix; internal: \0 prefix on resolved ID |
Missing \0 prefix lets other plugins process the virtual module |
| P-10 | moduleParsed hook NOT relied upon in dev |
NEVER depend on moduleParsed during development |
This hook is skipped in dev for performance — code silently fails |
| P-11 | v8: moduleType: 'js' set in load/transform for non-JS |
ALWAYS set moduleType: 'js' when returning non-JS content |
Rolldown cannot process content without explicit module type |
What ships with it
3 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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.
- 12d ago First seen · 171 lines · 112 tokens per session scan A 9ce9f5f3138b
vite-agents-review is a skill published in the GitHub repository OpenAEC-Foundation/OpenAEC-Workspace-Composer (5 stars, last pushed 5mo ago), licensed MIT. It adds 112 tokens to every session and 2,960 once invoked, about $0.0006 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 skills, from other repositories
aios-review
A code-review workflow that examines changes for bugs, security and permission problems, performance issues, testing gaps, and agent-specific risks. For construction projects, it also checks items such as BIM, building rules, evidence, and audit records.
前端代码审查
A review checklist for browser-based front-end and React code. It covers security, accessibility, speed, React correctness, maintainability, and Forsion’s no-build environment rules.
qt-qml-review
Invoke when the user asks to review, check, audit, or look over Qt6 QML code -- or suggest before committing. Runs deterministic linting (47+ rules) then six parallel deep- analysis agents covering bindings, layout, loaders, delegates, states, and performance. Optionally invokes system qmllint for type-level checks.…
verify-behavior
Verify or reproduce visible product behavior by driving the real UI with pi-computer-use's checked tools, requiring verified expect postconditions and durable state evidence for meaningful UI flows. Use when triage needs visual reproduction, implementation needs behavioral proof, review needs interactive confirmation…
recipe-front-review
Reviews completed frontend implementation for governing-source compliance, scope economy, repository quality, and security, then applies user-approved React corrections.
qa-frontend
Internal PostHog developer frontend/browser QA skill. Use only when a PostHog developer explicitly asks to run frontend QA, browser-test a PR, verify a UI flow against the local PostHog stack, use qa-frontend, or QA current frontend changes with browser/runtime evidence. Do not use for generic code review, PR review…