菜单
Reviews a running app's user experience by walking through every screen (or command/endpoint surface) and writing severity-tagged findings to docs/UI-UX-REVIEW.md. Use when the user asks for a UI review, UX walkthrough, design QA, or a "does the app feel right" pass on a live app.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Runs a full QA engagement for an app: e2e test plan and execution, UI/UX walkthrough review, and static frontend review — up to three docs in the project's docs/. Use when the user asks to "QA this app", "test and review the app", or wants the full treatment; for a single activity invoke e2e-testing, ui-ux-review, or frontend-review directly.
Plans and runs end-to-end tests against a running app — web, API, CLI, TUI, or mobile — producing docs/E2E-TEST-PLAN.md with executable scenarios and walkthrough results. Use when the user asks to e2e-test an app, verify user flows end to end, do a test walkthrough, or write an e2e test plan.
Static source review of an app's interface layer — API client and auth plumbing, state management, component quality, i18n, type safety, accessibility, test coverage, build hygiene — written to docs/FRONTEND-REVIEW.md. Use when the user asks for a frontend code review or a source-level complement to live testing. Runs without the app running.
The structural model of an autonomous loop — the four loop types (turn-based, goal-based, time-based, proactive), the six components, and inner/outer layering — for designing a loop rather than one-off prompting. Consult when turning a repeated task into a loop, picking the right loop type, deciding what a loop must contain to run unattended, or when the user asks to "set up a loop / make this run on its own". For the native Workflow tool's orchestration patterns see dynamic-workflows; for the operational safety checklist see "Safe autonomous loops" in CLAUDE.md.
Self-writing vault — a single-inbox markdown vault for the USER'S raw project thinking (voice transcripts, quick notes, half-ideas), which Claude files, cross-links, and synthesizes on a schedule without the user. Operations: init (scaffold), process (inbox → linked notes + daily digest), synthesize (weekly themes/contradictions), health (graph pulse). Use when the user wants to set up a vault, capture a thought mid-session, process the inbox, or run note upkeep unattended. Distinct from knowledge-wiki (digests an EXTERNAL source corpus) and basic-memory (cross-project decision graph).
Control layer for frontend visual design work — landing pages, hero sections, portfolios, marketing sites, redesigns, "make it look good / premium / not generic". Reads the brief, routes to the right globally-installed taste-skill variant (design-taste-frontend, minimalist-ui, industrial-brutalist-ui, high-end-visual-design, redesign-existing-projects), and composes a section-by-section master design prompt from the archetype templates in references/. For API/module interface shape use design-an-interface instead; for dashboards and data-heavy product UI this skill mostly does not apply.
| name | ui-ux-review |
| description | Reviews a running app's user experience by walking through every screen (or command/endpoint surface) and writing severity-tagged findings to docs/UI-UX-REVIEW.md. Use when the user asks for a UI review, UX walkthrough, design QA, or a "does the app feel right" pass on a live app. |
| user-invocable | true |
| argument-hint | ["app-path-or-description"] |
Your task is to review the running app's user experience surface by surface and write docs/UI-UX-REVIEW.md in the target project.
Baseline — Establish and record the vantage point: profile/role, viewport, theme, locale, date. The review is a snapshot from a stated baseline, not a universal claim.
Access the app — Reuse the driver detection in e2e-testing's driving-tools reference if installed alongside; otherwise probe ToolSearch for a browser/device driver. No driver → paired mode: the user walks, shares screenshots and observations, you record.
Walk every surface — Follow references/review-rubric.md: global findings first, then one section per screen, each finding tagged 🔴/🟡/🔵. For CLI/API apps the rubric's adaptation table redefines "screen".
Sweep beyond the happy path — The rubric's checklist: both themes, narrow viewport, i18n leaks and diacritics, empty states, loading states, error states.
Record what works — A "What already works well (keep)" section is part of the doc: it protects good patterns from churn and keeps the review actionable.
Close with fix order — A short numbered list: severity first, cheap-and-visible next.
e2e-testing.frontend-review; here record the observed symptom.