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-data/skills/chart-data-extractor/SKILL.md

@@ -84,6 +84,13 @@ Ask the user which of these they want:
 - [ ] Assumptions about axis scale and interpolation are stated
 - [ ] CSV output is clean and directly usable
 
+## Anti-Patterns
+
+- [ ] Do not silently include low-confidence data points in the main table — flag them separately so the user knows which values to verify
+- [ ] Do not assume a linear scale without confirming it — logarithmic axes make extracted values incorrect by orders of magnitude if misread
+- [ ] Do not report extracted values with false precision — if the chart's Y-axis only shows gridlines every 10 units, a reported value of 37 is invented, not extracted
+- [ ] Do not omit the assumptions and caveats section — partial image quality, overlapping bars, or unlabelled axes must be disclosed
+
 ## Example Trigger Phrases
 - "Extract the data from this chart"
 - "Transcribe the numbers in this graph"

plugins/pm-data/skills/cohort-analysis/SKILL.md

@@ -178,6 +178,14 @@ ORDER BY 1, 3;
 - [ ] Recommendations are tied to specific cohort or segment findings — not generic growth advice
 - [ ] Leading indicators are observable in production data, not just in theory
 
+## Anti-Patterns
+
+- [ ] Do not allow the same user to appear in multiple cohorts — overlapping cohorts produce retention numbers that cannot be compared or acted upon
+- [ ] Do not assume assumed ARPU in LTV projections — use observed revenue per retained user per period, not a blended average that hides segment differences
+- [ ] Do not draw conclusions from cohorts too small to be statistically meaningful — flag minimum cohort size thresholds and note when a cohort is too small to trust
+- [ ] Do not conflate retention rate with engagement rate — a user who logs in but does not complete the key retention event is not retained by the definition used
+- [ ] Do not make recommendations without connecting them to specific cohort or segment findings — generic growth advice that could apply to any product adds no value
+
 ## Example Trigger Phrases
 
 - "Run a cohort analysis for our SaaS product"

plugins/pm-data/skills/dashboard-brief/SKILL.md

@@ -114,6 +114,14 @@ Flag any fields that may not exist in current data infrastructure.
 - [ ] Data requirements section flags any missing fields
 - [ ] Filters are practical and don't require IT to configure
 
+## Anti-Patterns
+
+- [ ] Do not specify metrics that the available data sources cannot actually support — always validate data availability
+- [ ] Do not include more than 8–10 primary metrics on a single dashboard — more creates noise, not insight
+- [ ] Do not skip the primary business question — a dashboard without a north-star question becomes a vanity metrics display
+- [ ] Do not choose chart types for aesthetic reasons — every chart type must match the data relationship it represents
+- [ ] Do not leave filter configurations vague — specify exact filter values, not just filter categories
+
 ## Example Trigger Phrases
 
 - "Design a dashboard to track [business process]"

plugins/pm-data/skills/data-pipeline-spec/SKILL.md

@@ -212,6 +212,14 @@ List each transformation in execution order. For ELT pipelines, this is the dbt
 - [ ] Failure modes include a documented recovery owner
 - [ ] PII fields are identified and a treatment plan is specified
 
+## Anti-Patterns
+
+- [ ] Do not spec a pipeline without defining SLAs — "as fast as possible" is not an acceptable freshness target
+- [ ] Do not omit error handling and dead-letter queue strategy — every pipeline must specify what happens to failed records
+- [ ] Do not design idempotent loads without documenting the deduplication key — assume reruns will happen
+- [ ] Do not leave data quality rules implicit — schema validation, null checks, and referential integrity must be explicit
+- [ ] Do not ignore schema evolution — specify how upstream schema changes are detected and handled
+
 ## Example Trigger Phrases
 
 - "Design a data pipeline for our Salesforce to Snowflake sync"

plugins/pm-data/skills/metrics-framework/SKILL.md

@@ -94,6 +94,14 @@ Suggest a 3-tier dashboard structure:
 - [ ] Dashboard tiers are tailored to the product stage
 - [ ] All metric definitions are unambiguous (formula or clear description)
 
+## Anti-Patterns
+
+- [ ] Do not set a North Star metric that measures business activity (revenue, pageviews) rather than customer value delivered — this creates incentives misaligned with product quality
+- [ ] Do not define metrics without specifying the formula or data source — an ambiguous metric will be measured differently by different people
+- [ ] Do not skip counter-metrics — optimising any single metric without a guard rail will eventually produce perverse incentives
+- [ ] Do not include more than 4–5 metrics in a daily team view — a dashboard with 20 metrics is a dashboard nobody looks at
+- [ ] Do not classify all metrics as "leading" — be honest about which are lagging outcome metrics and which genuinely predict future outcomes
+
 ## Example Trigger Phrases
 
 - "Build a metrics framework for [product]"

plugins/pm-data/skills/sql-query-explainer/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: sql-query-explainer
-description: "Explain, optimise, or translate SQL queries into plain language. Use when asked to explain a SQL query, optimise slow SQL, write a data dictionary, translate SQL to plain English for non-technical stakeholders, or review a query for correctness and performance. Works across PostgreSQL, MySQL, BigQuery, Snowflake, and standard SQL."
+description: "Explains, optimises, writes, and documents SQL queries. Use when asked to explain a SQL query, optimise slow SQL, translate SQL to plain English for non-technical stakeholders, write a query from a natural language description, or produce query documentation. Produces plain-English explanations, annotated optimised queries, or a data dictionary covering output shape, assumptions, and known limitations. Works across PostgreSQL, MySQL, BigQuery, Snowflake, and standard SQL."
 ---
 
 # SQL Query Explainer Skill