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.
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.
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.
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.