fix(plugins): sync all 171 plugin SKILL.md files with fixed skills/ versions
Propagates Anti-Patterns sections, description rewrites, Required Inputs additions, and Quality Checks format fixes from skills/ to matching plugin SKILL.md copies. https://claude.ai/code/session_01MuGKn3a3Gbqoe8uM5Lmuqt
This commit is contained in:
Mohit
@@ -167,6 +167,14 @@ Ask the user for these if not provided:
|
||||
- [ ] Effort estimates are included for prioritisation
|
||||
- [ ] Testing recommendations are included
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not rely solely on automated scanning tools — automated checks catch ~30% of issues; manual keyboard and screen reader testing is required
|
||||
- [ ] Do not label an issue "minor" simply because it only affects a small percentage of users — for those users it may block all access
|
||||
- [ ] Do not add ARIA roles to fix broken semantics — use correct semantic HTML first; ARIA is a last resort
|
||||
- [ ] Do not confuse colour contrast of text with colour contrast of UI components — they have different minimum ratios (4.5:1 vs 3:1)
|
||||
- [ ] Do not audit only the happy path — error states, empty states, and loading states must also meet accessibility requirements
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- "Audit this design for accessibility"
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: design-critique
|
||||
description: "Give structured, constructive feedback on any design. Use when asked to critique a design, review a UI, give feedback on a Figma file or wireframe, assess a user flow, or evaluate a design against UX principles. Applies Jobs-to-be-Done, Gestalt principles, and usability heuristics to give actionable feedback."
|
||||
description: "Gives structured, constructive feedback on any design using UX frameworks. Use when asked to critique a design, review a UI, give feedback on a Figma file or wireframe, assess a user flow, or evaluate a design against UX principles. Applies Jobs-to-be-Done, Gestalt principles, and usability heuristics to give actionable feedback with prioritised issues and specific recommendations."
|
||||
---
|
||||
|
||||
# Design Critique Skill
|
||||
@@ -121,6 +121,14 @@ Prioritised list of the 3 most impactful changes. Each should be actionable in t
|
||||
- [ ] Priority levels (High/Medium/Low) reflect actual impact on user goal
|
||||
- [ ] Heuristic assessment only covers visible elements
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not lead with visual preference (e.g. "I don't like the colour") — every issue must reference a UX principle or user impact
|
||||
- [ ] Do not invent problems in the "What's Working" section — manufactured praise undermines the entire critique
|
||||
- [ ] Do not provide the same priority level (High/Medium/Low) to every issue — prioritisation requires genuine judgment about user impact
|
||||
- [ ] Do not skip the JTBD section for product screens — connecting feedback to the user's job-to-be-done is what separates UX critique from aesthetic opinion
|
||||
- [ ] Do not give recommendations that require a full redesign when the user is in high-fidelity — scope recommendations to the design stage
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- "Critique this design: [description or image]"
|
||||
|
||||
@@ -206,6 +206,14 @@ For each component, assess against these quality criteria:
|
||||
- [ ] Both Figma and code (Storybook/implementation) are assessed — not just Figma
|
||||
- [ ] Stakeholders from design, engineering, and product have reviewed the audit
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not assess only the Figma library without checking the code implementation — Figma-code drift is one of the most common and costly design system failures
|
||||
- [ ] Do not score adoption without interviewing teams — audit tool metrics miss the human reasons teams build custom components instead of using the system
|
||||
- [ ] Do not treat all component gaps equally — prioritise gaps based on how many production screens rely on custom implementations, not alphabetically
|
||||
- [ ] Do not recommend adding more components without first auditing documentation quality — an undocumented component is often worse than no component
|
||||
- [ ] Do not schedule remediation without a named owner per initiative — design system improvements without ownership consistently stall
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- "Audit our design system for consistency and coverage"
|
||||
|
||||
@@ -152,6 +152,14 @@ For each insight: "This means we should [design/product implication]" or "This c
|
||||
- [ ] Synthesis framework is included
|
||||
- [ ] Incentive recommendation is included
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not write a research plan without clearly stated research objectives — every methodology choice must flow from the objectives
|
||||
- [ ] Do not design a plan that mixes generative and evaluative research without clearly separating them
|
||||
- [ ] Do not omit screener criteria — recruiting unqualified participants invalidates the research
|
||||
- [ ] Do not write discussion guide questions that are leading — questions must be neutral and open-ended
|
||||
- [ ] Do not skip the incentive recommendation — uncompensated research has lower participant quality and completion rates
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- "Write a research plan for [feature or product area]"
|
||||
|
||||
Reference in New Issue
Block a user