Perform a read-only audit of an existing product interface, prove UI findings from governing design evidence and runtime paths, and prepare implementation-ready recommendations or plans. Use for review and design-system drift analysis; do not use when the user asks to implement fixes directly.
The English summary is being prepared. Showing the original description.
Run score Not tested
See how to installReview the instructions the agent will receive before you install.
Audit one coherent product surface against the system that actually governs it. Prefer a small set of well-proven findings to a long list of stylistic opinions.
Start from the route, screen, component family, or user journey in scope. Follow the actual path through layouts, compositions, components, variants, tokens, and resolved styles. Similar names and nearby files are candidates, not proof that an owner affects the surface.
Record the surface, relevant owners, design sources, explicit exceptions, and the current revision when available.
Use current, governing evidence only:
Drafts and proposals describe future intent unless the repository marks them as accepted. Missing documentation is not itself a UI defect.
A finding survives only when it has:
Reject a candidate when the evidence supports multiple incompatible fixes, the difference is an intentional exception, or the proposed correction primarily changes business behavior.
Re-open the cited sources and actively look for counterevidence before reporting.
Return no more than five findings, ordered by user impact, confidence, reach, and correction cost:
## Audit scope
- Surface:
- Governing evidence:
- Runtime owners:
- Explicit exceptions:
## Findings
| # | Observed problem | Evidence and connection | Required correction | Reach | Confidence |
|---|---|---|---|---|---|
## Highest-leverage change
<One finding, or “No supported recommendation.”>
If nothing passes the proof test, say so plainly. Do not pad the report.
When the user selects a finding or explicitly requests a plan, read references/change-plan.md. Write one self-contained plan per root correction. The executor must not need the audit conversation to understand ownership, scope, preservation requirements, or validation.
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Review or implement interface accessibility for semantics, keyboard operation, focus, contrast, status communication, zoom, and assistive technology. Use when accessibility is explicitly requested, required by the product contract, or a changed interaction creates substantial accessibility risk. Do not activate for every visual edit or use it as a generic design audit.
The English summary is being prepared. Showing the original description.
Implement, harden, or review defensive security controls for REST APIs, including authentication and authorization boundaries, validation, rate limiting, abuse prevention, resource limits, SSRF defenses, safe errors, logging, and security tests. Use when API security, endpoint hardening, threat review, rate limiting, token handling, or sensitive business-flow protection is an explicit concern. Do not use for ordinary endpoint logic without meaningful security scope or for offensive exploitation.
The English summary is being prepared. Showing the original description.
Design, implement, or assess project structure, module ownership, dependency boundaries, and safe file or folder organization. Use when project architecture, feature placement, separation of responsibilities, or architectural refactoring is a primary concern, including new framework projects. For a read-only assessment, do not modify files unless the user also requests changes; do not activate merely because ordinary feature work adds a file.
The English summary is being prepared. Showing the original description.
Review a code change, diff, commit, branch, or pull request for actionable defects, regressions, security risks, compatibility breaks, and missing verification. Use when code review is the primary requested outcome. Keep the review read-only unless the user explicitly asks to implement fixes; do not use as a substitute for implementation or a specialized visual audit.
The English summary is being prepared. Showing the original description.
Add, revise, or remove source-code comments while preserving executable behavior. Use for comment-only cleanup, documentation comments, TODO quality, and reducing narration. Do not use when the requested change modifies logic.
The English summary is being prepared. Showing the original description.
Write or revise user-facing product and marketing copy with a specific voice, verifiable claims, natural rhythm, and useful actions. Use for interface labels, onboarding, landing pages, help text, and product messaging. Do not use for code comments or neutral technical documentation unless tone editing is requested.
The English summary is being prepared. Showing the original description.