Design or review product experiences through user goals, journeys, information architecture, task flows, interaction models, feedback, recovery, and cross-screen continuity. Use when the primary question is how users understand and complete a goal across steps or surfaces. Do not use for visual styling, implementation-only logic, or unsupported user-research claims.
中文简介正在准备中。当前显示原文说明。
实测评分 未实测
查看安装方法安装前可以查看交给 AI 代理的指令内容。
Make the user's path to a meaningful outcome clear, coherent, and recoverable. Base decisions on product evidence and observable behavior; never invent research, personas, or confidence that the project does not support.
Before proposing a flow, identify:
Separate observed evidence from assumptions. Ask for direction when competing assumptions would change who the product serves, what consent means, or what outcome counts as success. Otherwise, use the smallest reversible assumption and state it.
Read references/journeys-task-flows-and-information-architecture.md when work spans multiple steps, screens, roles, entry points, or navigation levels.
For each consequential action, define what the user can observe before, during, and after it. Cover pending, success, partial success, validation failure, dependency failure, cancellation, and retry only where they can occur.
Read references/interaction-feedback-and-recovery.md when the flow contains forms, asynchronous work, destructive actions, external handoffs, interruption, or multi-step state.
Do not optimize completion by concealing cost, consent, security consequences, destructive effects, or meaningful alternatives. Preserve entered data after expected failures when safe, and return the user to a useful state rather than a dead end.
Walk through representative scenarios from entry to outcome, including at least one material failure or interruption. Check whether users can answer:
Read references/ux-evaluation-and-evidence.md for heuristic reviews, evidence quality, scenario selection, and usability validation. Describe findings as risks or observed problems at the confidence level the evidence supports; do not present an expert walkthrough as user research.
Load only the skills whose contracts materially change:
superior-ui for visual hierarchy, component composition, and interface implementation;superior-logic for domain behavior, state transitions, APIs, and persistence;superior-responsive for viewport-driven reflow and adaptive navigation;superior-accessibility for keyboard, focus, semantics, assistive technology, and inclusive interaction;superior-copy for labels, instructions, errors, and product voice;superior-testing for dedicated journey, contract, or regression test design;superior-docs when the resulting experience contract must remain durable.Do not edit implementation when the user asks only for a journey, flow, or review. When implementation is requested, use this skill to govern the experience contract and the owning implementation skills to change code.
Report the current and proposed journey, changed decisions or information structure, interaction and recovery contract, supporting evidence, unresolved assumptions, and validation performed. Prefer a compact flow or state table when sequence or branching would be harder to understand in prose.
还没有评价。欢迎分享你的使用感受。
无需登录即可发表。欢迎分享使用感受、提问，或说明在哪些环境下无法运行。
还没有评论。来写第一条吧。
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.
中文简介正在准备中。当前显示原文说明。
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.
中文简介正在准备中。当前显示原文说明。
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.
中文简介正在准备中。当前显示原文说明。
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.
中文简介正在准备中。当前显示原文说明。
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.
中文简介正在准备中。当前显示原文说明。
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.
中文简介正在准备中。当前显示原文说明。