Menu
Use when writing any user-facing text (UI labels, toasts, errors, empty states) or choosing UI components. Ensures plain language, consistent component usage, and human-first design.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Use after implementing a change or opening a PR — proves the change works end-to-end by running the app, driving it in the browser, and recording an MP4 video as proof. The reviewer watches the recording and merges without pulling the branch.
Use when starting any feature (small or large), resuming work after context loss, or unsure if a feature plan already exists. For smaller features, use lightweight mode (no plan file, but all PDD rules still apply).
Use for any code change — bug fix, small feature, refactor, or improvement. Ensures TDD, clarifying questions, codebase investigation, DRY, proper branching/worktrees, UI skills, and doc updates. PDD invokes this automatically for large features.
Use when fixing a bug — enforces reproduce-first-then-fix discipline with a strict step-by-step protocol. Prevents wrong-approach loops by gating each step on success criteria.
Reconcile shipped code with the plan in both directions — additive drift (unplanned work that landed) and subtractive drift (dead files, stale TODOs, completed deferred items). Run as part of PDD's post-completion audit, before /simplify.
Generate 5 meaningfully distinct UI/UX variants of the same screen in parallel (one subagent each), reachable via ?style=1...5, so the user can compare and pick. Calling again on a chosen style refines within that direction.
| name | simple-design-principles |
| description | Use when writing any user-facing text (UI labels, toasts, errors, empty states) or choosing UI components. Ensures plain language, consistent component usage, and human-first design. |
Rules for writing user-facing copy and choosing UI components. Apply these whenever a code change touches anything the user sees — labels, toasts, error messages, empty states, buttons, modals, tooltips.
best-practices and plan-driven-development invoke this automatically for UI work, but you can use it directly for copy-only changes.
Write for business users, not developers. A high schooler should understand every word.
| Component | Rule | Example |
|---|---|---|
| Toast messages | Short and conversational. 1 short sentence max for the description. | "Website added" / "Changes saved" |
| Button labels | Action-oriented and specific. Say what clicking does. | "Add website" not "Submit". "Turn on tickets" not "Enable tickets". |
| Empty states | Encouraging. Tell the user what to do next, not describe system state. | "Add your first website to get started" not "No websites configured" |
| Error messages | Blame the system, not the user. Suggest a next step. | "Something went wrong. Try again." not "Invalid request payload" |
| Tooltips | One sentence explaining why this matters or what it does. | "Visitors will see this name in the chat window" |
| Page titles | Plain text, no icons in h1. Describe what the page is for. | "Knowledge vault" not "📚 Knowledge vault" |
| Descriptions | One line under the title explaining what the user can do here. | "Add websites and articles your assistant can search" |
Use the project's UI library consistently. Don't mix custom implementations with library components.
text-lg font-semiboldThis skill provides generic design principles. Always check the project's CLAUDE.md for additional project-specific UI instructions — these take precedence. Projects may define:
Copy:
- No jargon, no tech words
- Short sentences, one idea each
- Lead with what to do, not what went wrong
- Apple-like tone: confident, helpful, warm
Components:
- Use library components, not custom
- Dialog for modals, Sheet for panels
- AlertDialog for destructive actions
- Follow existing patterns in the codebase