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
@@ -56,6 +56,14 @@ Touch targets, screen reader labels, focus order, colour contrast, motion prefer
|
||||
- [ ] Empty states specified
|
||||
- [ ] Edge cases listed as actionable questions
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not annotate only the happy path — error states, loading states, and empty states must all be documented
|
||||
- [ ] Do not use vague spacing descriptions like "some padding" — specify exact pixel values or token names
|
||||
- [ ] Do not skip accessibility annotations — focus order, ARIA labels, and colour contrast ratios must be included
|
||||
- [ ] Do not leave interaction behaviour undescribed — every interactive element needs a documented response
|
||||
- [ ] Do not produce annotations without edge cases — developers need to know what happens at boundaries
|
||||
|
||||
## Example Trigger Phrases
|
||||
- "Write dev annotations for this Figma screen"
|
||||
- "Create developer handoff notes for [screen/component]"
|
||||
|
||||
@@ -66,6 +66,14 @@ Naming convention to enforce:
|
||||
- [ ] Fix plan is ordered by impact-to-effort ratio
|
||||
- [ ] Variant completeness covers all interactive states
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not flag naming issues without providing a specific, consistent naming convention to adopt
|
||||
- [ ] Do not audit only visual consistency — also check for missing interactive states and accessibility compliance
|
||||
- [ ] Do not list all issues at equal priority — group by impact (Critical / Major / Minor) so the fix plan is actionable
|
||||
- [ ] Do not omit variant completeness — every interactive component must cover all required states
|
||||
- [ ] Do not leave coverage gaps without recommending specific missing components to add
|
||||
|
||||
## Example Trigger Phrases
|
||||
- "Audit my Figma component library"
|
||||
- "Review our design system for consistency issues"
|
||||
|
||||
@@ -60,6 +60,14 @@ Feature, PM, Designer, Platform, Design due, Dev handoff dates.
|
||||
- [ ] Constraints include accessibility requirements
|
||||
- [ ] Open questions have owners
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not write a design brief that describes the solution — the brief must describe the problem and constraints, not the design answer
|
||||
- [ ] Do not skip the success criteria — designers need to know what "done" looks like before starting
|
||||
- [ ] Do not omit existing components to reuse — briefs that ignore the design system lead to inconsistent implementations
|
||||
- [ ] Do not leave open questions unresolved — escalate them before design work starts, not during it
|
||||
- [ ] Do not confuse requirements with design instructions — the brief defines what, not how
|
||||
|
||||
## Example Trigger Phrases
|
||||
- "Write a design brief for [feature]"
|
||||
- "Turn this PRD into a Figma design brief"
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: figma-design-critique-pm
|
||||
description: "Run a PM-perspective design critique focused on product outcomes, user goals, and business requirements — not aesthetics. Use when asked for a PM design critique, a product review of a design, feedback on a Figma design from a product perspective, or when you want to critique a design without being a designer. Produces structured outcome-based feedback tied to user goals and business metrics."
|
||||
description: "Runs a PM-perspective design critique focused on product outcomes and user goals, not aesthetics. Use when asked for a PM design critique, a product review of a Figma design, or feedback from a product perspective without needing to be a designer. Produces structured outcome-based feedback tied to user goals, business metrics, and requirement coverage."
|
||||
---
|
||||
|
||||
# Figma Design Critique — PM Perspective Skill
|
||||
@@ -68,6 +68,14 @@ Approve / Approve with changes (list) / Revise and re-review (one focus area onl
|
||||
- [ ] PM recommendation is explicit
|
||||
- [ ] Evidence basis stated honestly
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not critique visual aesthetics — PM feedback must focus on product outcomes, user goals, and business requirements
|
||||
- [ ] Do not provide feedback without stating the evidence basis — distinguish between observed design facts and assumed user behaviour
|
||||
- [ ] Do not give vague feedback like "the flow feels confusing" — every concern must reference a specific screen state or interaction
|
||||
- [ ] Do not ignore what is working — balanced critique includes explicit acknowledgment of design decisions that are well-executed
|
||||
- [ ] Do not critique without knowing the design constraints — always ask about technical, time, or resource limitations before judging decisions
|
||||
|
||||
## Example Trigger Phrases
|
||||
- "Give me a PM critique of this design"
|
||||
- "Review this design from a product perspective"
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: figma-design-qa
|
||||
description: "Run a pre-handoff QA checklist on any Figma design before it goes to engineering. Use when asked to QA a Figma design, do a pre-handoff check, review a design before engineering, or validate a Figma file is ready to build. Produces a structured QA checklist covering file hygiene, component usage, accessibility, and handoff readiness with pass/fail status. Optimised for Opus 4.7 and newer models."
|
||||
description: "Runs a pre-handoff QA checklist on a Figma design before it goes to engineering. Use when asked to QA a Figma design, do a pre-handoff check, or validate a Figma file is ready to build. Produces a structured QA report covering file hygiene, component usage, accessibility, and handoff readiness with explicit pass/fail status per item. Optimised for Opus 4.7 and newer models."
|
||||
---
|
||||
|
||||
# Figma Design QA Skill
|
||||
@@ -81,6 +81,14 @@ Status, signed off by, date.
|
||||
- [ ] Blocking issues separated from minor ones
|
||||
- [ ] Handoff decision is explicit
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not produce a partial QA — every checklist category must be evaluated, not just the ones that are obviously problematic
|
||||
- [ ] Do not leave the handoff decision ambiguous — the output must explicitly state pass, pass with conditions, or fail
|
||||
- [ ] Do not skip accessibility checks — colour contrast, tap target size, and screen reader labels are required, not optional
|
||||
- [ ] Do not report issues without specifying which screen or component they appear on
|
||||
- [ ] Do not approve a design if any component is detached from the library without a documented reason
|
||||
|
||||
## Example Trigger Phrases
|
||||
- "QA this Figma design before handoff"
|
||||
- "Run a pre-handoff check on [feature] design"
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: figma-design-review
|
||||
description: "Run a structured PM design review against product requirements. Use when asked to review a Figma design, check a design against requirements, do a PM design review, or assess whether a design meets the product spec. Produces a requirements coverage check, UX concerns, open questions, and explicit approval status."
|
||||
description: "Runs a structured PM design review against product requirements. Use when asked to review a Figma design, check a design against requirements, or assess whether a design meets the product spec. Produces a requirements coverage check, UX concerns, open questions, and an explicit approval status — approved, approved with conditions, or not approved."
|
||||
---
|
||||
|
||||
# Figma Design Review Skill
|
||||
@@ -60,6 +60,14 @@ Approved / Approved with changes (list) / Needs revision (focus area + next revi
|
||||
- [ ] Open questions have owners
|
||||
- [ ] Approval status is explicit
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not review a design without a list of requirements to check against — always ask for the PRD, design brief, or acceptance criteria first
|
||||
- [ ] Do not give a vague approval status — the decision must be explicitly "approved", "approved with conditions", or "not approved"
|
||||
- [ ] Do not conflate requirements gaps with UX concerns — track them separately so engineers and designers can act independently
|
||||
- [ ] Do not raise concerns without suggesting what information is needed to resolve them
|
||||
- [ ] Do not skip open questions — unresolved assumptions at review time become bugs after engineering handoff
|
||||
|
||||
## Example Trigger Phrases
|
||||
- "Review this Figma design against the requirements"
|
||||
- "Do a PM design review for [feature]"
|
||||
|
||||
@@ -76,6 +76,14 @@ Success when: [Specific trigger]
|
||||
- [ ] Success criteria defined for each task
|
||||
- [ ] Reset process defined for between participants
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not prototype everything — scope must be limited to the interactions that answer the specific research questions
|
||||
- [ ] Do not design prototype flows without also writing the test task scripts — the two must align exactly
|
||||
- [ ] Do not skip the reset process between participants — unsettled prototype state contaminates results
|
||||
- [ ] Do not plan a prototype without specifying which interactions are clickable vs static — ambiguity causes scope creep
|
||||
- [ ] Do not scope a prototype without first defining the research questions it needs to answer
|
||||
|
||||
## Example Trigger Phrases
|
||||
- "Plan the Figma prototype for our user test on [feature]"
|
||||
- "What interactions do I need to build for this prototype?"
|
||||
|
||||
@@ -69,6 +69,14 @@ Desktop (1440px): 12 columns, margin [value], gutter [value], max content width
|
||||
- [ ] Component conventions cover common decisions
|
||||
- [ ] Figma implementation steps included
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not create a spacing scale with arbitrary values — the scale must follow a consistent mathematical ratio (e.g. 4px base, 8-4-2 system)
|
||||
- [ ] Do not define spacing tokens without Figma implementation instructions — token names alone are not actionable
|
||||
- [ ] Do not create a spacing system that doesn't account for component-level spacing conventions — global tokens and component usage must both be documented
|
||||
- [ ] Do not skip grid definitions — spacing without a grid system is incomplete layout foundation documentation
|
||||
- [ ] Do not produce a spacing system that ignores responsive behaviour — define how spacing adapts across breakpoints
|
||||
|
||||
## Example Trigger Phrases
|
||||
- "Create a spacing system for our Figma design system"
|
||||
- "Define our spacing tokens for Figma"
|
||||
|
||||
@@ -68,6 +68,14 @@ Feature name/
|
||||
- [ ] Out-of-scope section is explicit
|
||||
- [ ] Figma file structure matches screen map
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not plan only the happy path — all error states, empty states, and edge cases must be mapped before designing starts
|
||||
- [ ] Do not produce a flow map that doesn't match the Figma file structure — the page structure must reflect the flow map
|
||||
- [ ] Do not define screens without specifying all required states — a screen without its variants is an incomplete design scope
|
||||
- [ ] Do not start designing before entry and exit points are fully documented — unclear boundaries cause scope creep
|
||||
- [ ] Do not plan user flows without tying each step back to a user goal — every screen must justify its existence
|
||||
|
||||
## Example Trigger Phrases
|
||||
- "Plan the user flow for [feature] in Figma"
|
||||
- "What screens do I need to design for [feature]?"
|
||||
|
||||
@@ -70,6 +70,14 @@ For each state, list only what changes from Default:
|
||||
- [ ] Token mapping covers all visual properties
|
||||
- [ ] Disabled state uses layer-level properties not opacity
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not create a variant matrix with properties that overlap or conflict — each property must be independently variable
|
||||
- [ ] Do not use opacity for disabled states — disabled states must use layer-level properties, not opacity
|
||||
- [ ] Do not enumerate every mathematical combination if many are invalid — document only valid, buildable combinations
|
||||
- [ ] Do not define variants without considering responsive behaviour — specify which properties change across screen sizes
|
||||
- [ ] Do not produce a matrix without Figma implementation guidance — variant naming conventions must follow Figma's property system
|
||||
|
||||
## Example Trigger Phrases
|
||||
- "Define the variants for a [component] in Figma"
|
||||
- "What states does my [component] need?"
|
||||
|
||||
Reference in New Issue
Block a user