justin/pm-claude-skills
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

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

Browse Source 
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
Download Patch File Download Diff File Expand all files Collapse all files
skills/figma-design-review/SKILL.md
+9 -1
View File
@@ -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]"