usabilitylisted

# /usability — Usability-First Design Enforcement Every design, plan, and implementation MUST be intuitive, forgiving, and self-documenting. Whether the consumer is an end user clicking a button or a developer calling an API, the experience MUST minimize confusion, surprise, and frustration. **Why this matters:** Systems that are hard to use don't get used — or they get used wrong. Poor usability causes support tickets, workarounds, data entry errors, and abandonment. The most technically correct system is worthless if nobody can figure out how to use it. **When to invoke:** During PLANNING (after `/gsd:discuss-phase`, before `/gsd:plan-phase`) and during REVIEW (as part of code review criteria). This skill applies to user interfaces, APIs, CLIs, configuration files, error messages, and documentation. --- ## The Rules ### Rule 1: Principle of Least Surprise Everything MUST behave as users expect. If a user predicts what will happen before they act, the design is working. - **Name things by what they do**, not how they do it. `calculateTotal()` not `runAlgorithm3()`. - **Follow platform conventions.** If every other CLI uses `--verbose`, don't use `--detailed-output`. - **Be consistent.** If `getUser()` returns a user object, `getOrder()` returns an order object — not a tuple. - **Side effects are surprises.** If a function does more than its name suggests, rename it or split it. **Test:** Can a new team member predict what this function/button/endpoint does from its