fix(skills): add Anti-Patterns and fix descriptions for remaining skills (batch 3)

Processed 27 skills: teaching-lesson-plan through feature-prioritisation and all figma skills.
Added Anti-Patterns sections to all 27 skills.
Added Quality Checks section to financial-due-diligence (was missing entirely).
Converted user-research-synthesis Quality Standards to binary checkbox format.
Rewrote descriptions for figma-design-critique-pm, figma-design-qa, figma-design-review,
team-health-check, and user-interview-synthesis.

https://claude.ai/code/session_01MuGKn3a3Gbqoe8uM5Lmuqt
This commit is contained in:
Mohit
2026-06-08 13:01:36 +00:00
parent f170eed437
commit fb85a1cb55
27 changed files with 234 additions and 18 deletions
+9 -1
View File
@@ -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"