Ux Visual Evaluation
Use after visual-feedback-loop confirms basic correctness, or when UI changes are complete and a screenshot is available, to evaluate screenshots for visual design quality — hierarchy, whitespace, affordances, and consistency
Ux Design Principles
Use when planning or designing features that involve user-facing UI, or before writing code for any new user-facing feature — pages, components, flows, or interactions — to apply user-centered design thinking before implementation begins
Ux Prototyping
Use after designing a UI feature when the design involves novel interactions, complex multi-step flows, or layouts where visual balance matters — to build a throwaway HTML prototype for user validation before implementation
Visual Feedback Loop
Use after implementing a UI change or before committing UI changes to visually verify the application looks correct — applies when the current task changes visible UI (components, styling, layout, or content)
React Best Practices
Use when reviewing React component code during code quality review, when the diff contains .tsx or .jsx files, or when reviewing components that use React hooks, state management, or data fetching patterns
Git Commit Message
Use when about to write a git commit message, before running git commit — applies when staged changes are ready and a message needs to be drafted
Boy Scout Rule
Use after making tests pass to apply incremental refactoring improvements to touched code and its immediate neighbors, during code review, or before committing changes
Domain Driven Design
Use when planning features that involve business logic or domain modeling, and during code review to check naming consistency and module boundary violations — applies strategic DDD patterns
Functional Core Imperative Shell
Use when reviewing code that mixes business logic with I/O, database calls, or side effects, or when tests require extensive mocking to verify logic
Architecture Decision Records
Use when making architectural decisions during planning or design sessions, when choosing between technologies, patterns, or system designs that affect multiple components or are hard to reverse
Revise For Clarity
Revise existing prose to be shorter and clearer: a design doc, RFC, ADR, proposal, PR or ticket description, status update, email, or any passage carrying an argument. Use ONLY on text that already exists, and ONLY when the user explicitly invokes this skill. Triggers on "revise this for clarity", "make this shorter and clearer", "tighten this up", "edit this down", "this is dense and hard to fol…