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

plugins/pm-discovery/skills/assumption-mapper/SKILL.md

@@ -51,6 +51,13 @@ Input: *"We're building a self-serve onboarding flow to reduce time-to-value for
 | Faster onboarding correlates with higher retention | Viability | 3 | 4 | 1 | Cohort analysis of current onboarding times vs. 90-day retention |
 | The current onboarding is the primary reason for slow time-to-value | Desirability | 2 | 4 | 2 | User interviews with recent churned SMB accounts |
 
+## Anti-Patterns
+
+- [ ] Do not only surface desirability assumptions — feasibility and viability assumptions are equally likely to kill a product and are often overlooked
+- [ ] Do not assign high confidence to an assumption just because it hasn't been challenged yet — absence of evidence is not evidence
+- [ ] Do not recommend "user interviews" as the validation method for every assumption — some assumptions require quantitative data, competitive analysis, or technical spikes
+- [ ] Do not list assumptions that cannot be tested — every assumption in the map must have a plausible validation method, or it should be flagged as unknowable and treated as a risk
+
 ## Quality Checks
 
 - [ ] At least one assumption per category (Desirability, Feasibility, Viability, Usability)

plugins/pm-discovery/skills/customer-journey-map/SKILL.md

@@ -206,6 +206,14 @@ Low   😤 │                        *    *
 - [ ] Emotion curve shows the real experience — not an aspirationally positive version
 - [ ] Research gaps are documented — the map reflects what is known, not assumed
 
+## Anti-Patterns
+
+- [ ] Do not build the map from assumptions alone — ground at least the pain points in real customer data or research
+- [ ] Do not treat all journey stages as equally weighted — identify the highest-friction moments explicitly
+- [ ] Do not omit the emotional layer — a journey map without emotions is a process flow, not a customer map
+- [ ] Do not create generic touchpoints that apply to any product — each touchpoint must be specific to this product and customer
+- [ ] Do not leave opportunities unranked — prioritise by impact and feasibility
+
 ## Example Trigger Phrases
 
 - "Map the customer journey for [product]"

plugins/pm-discovery/skills/discovery-interview-guide/SKILL.md

@@ -105,3 +105,11 @@ Ask the user for these if not provided:
 - If user is new to interviewing: remind them to stay silent after asking a question (aim for 80/20 participant-to-interviewer talking ratio)
 - Never synthesise during the interview — do it after, when you can look across sessions
 - Flag confirmation bias: if user writes questions that lead toward a predetermined answer, rewrite them as open-ended alternatives
+
+## Anti-Patterns
+
+- [ ] Do not use future-tense questions ("Would you use this?") — hypothetical responses do not predict real behaviour and produce false confidence in an idea
+- [ ] Do not mention your product or solution before problem exploration is complete — doing so anchors the participant's responses and invalidates the discovery
+- [ ] Do not synthesise across fewer than 5 interviews — themes from 2–3 interviews reflect anecdote, not pattern; wait for saturation
+- [ ] Do not write screener questions that are too easy to pass — if participants can guess the "right" answer, you will recruit the wrong people
+- [ ] Do not treat participant opinions as evidence of future behaviour — what people say they will do consistently diverges from what they actually do

plugins/pm-discovery/skills/job-story-mapper/SKILL.md

@@ -114,6 +114,22 @@ Rate each job story on:
 - [ ] Current workaround identified for each high-opportunity story
 - [ ] Product opportunity is distinct from "build the feature" (it's an outcome)
 
+## Required Inputs
+
+Ask the user for these if not provided:
+- **Product or feature area** to map (e.g. onboarding, checkout, dashboard)
+- **User type or persona** (who are we mapping jobs for?)
+- **Source material** (user interview notes, support tickets, discovery findings, or describe from memory)
+- **Scope** (full product job map vs. a single feature area)
+
+## Anti-Patterns
+
+- [ ] Do not write job stories that describe a feature rather than a situation-motivation pair
+- [ ] Do not skip the social and emotional dimensions — mapping only functional jobs misses the most defensible differentiation opportunities
+- [ ] Do not define situations too broadly ("as a user who wants to manage their work") — the situation must be a specific moment or trigger
+- [ ] Do not conflate opportunity scoring with priority — a high opportunity score still requires feasibility and strategic fit assessment
+- [ ] Do not produce a job map without identifying current workarounds — the workaround reveals what the job is worth to the customer
+
 ## Guidelines
 
 - Never write a job story for a feature — write it for the situation that makes the feature valuable

plugins/pm-discovery/skills/user-interview-synthesis/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: user-interview-synthesis
-description: "Synthesise user interview transcripts into structured research findings. Use when asked to analyse interview notes, synthesise qualitative research, identify themes from user interviews, or turn raw interview data into actionable product insights. Produces a themed synthesis with supporting quotes, 'so what' implications, and recommended next steps."
+description: "Synthesises user interview transcripts into structured research findings. Use when asked to analyse interview notes, synthesise qualitative research, identify themes from interviews, or turn raw interview data into actionable product insights. Produces a themed synthesis with supporting quotes per theme, 'so what' implications, and recommended next steps."
 ---
 
 # User Interview Synthesis Skill
@@ -50,3 +50,11 @@ Ask the user for these if not provided:
 - [ ] Researcher bias check: no leading language, findings don't all support one hypothesis
 - [ ] Single-source signals are flagged separately, not mixed into main themes
 - [ ] Research questions from the study brief are each addressed (even if the answer is "inconclusive")
+
+## Anti-Patterns
+
+- [ ] Do not mix single-source signals into main themes — insights cited by only one participant must be flagged separately
+- [ ] Do not write implications that are observations restated rather than product decisions enabled
+- [ ] Do not include themes that only support the project hypothesis — contradictory findings must be surfaced, not omitted
+- [ ] Do not present findings without quotes — every theme requires verbatim evidence from at least 3 participants
+- [ ] Do not leave research questions unanswered — each question from the study brief must be explicitly addressed, even if the answer is inconclusive