القائمة
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.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
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