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

fix(plugins): sync all 171 plugin SKILL.md files with fixed skills/ versions

Browse Source 
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
2026-06-08 13:06:21 +00:00
parent fb85a1cb55
commit affae033fe
171 changed files with 1428 additions and 56 deletions
Download Patch File Download Diff File Expand all files Collapse all files
plugins/pm-figma/skills/figma-design-critique-pm/SKILL.md
+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"