From affae033fea9b4fc8a0bfdb4562b2fa07758149f Mon Sep 17 00:00:00 2001 From: Mohit Date: Mon, 8 Jun 2026 13:06:21 +0000 Subject: [PATCH] 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 --- .../skills/ai-ethics-review/SKILL.md | 10 ++++++- .../skills/ai-product-canvas/SKILL.md | 8 ++++++ .../skills/design-handoff-brief/SKILL.md | 8 ++++++ .../skills/experiment-designer/SKILL.md | 8 ++++++ .../multi-source-signal-synthesiser/SKILL.md | 10 ++++++- .../skills/data-analysis-standard/SKILL.md | 8 ++++++ .../skills/product-health-analysis/SKILL.md | 8 ++++++ .../skills/retention-analysis/SKILL.md | 8 ++++++ .../skills/board-deck-narrative/SKILL.md | 8 ++++++ .../skills/investor-update/SKILL.md | 8 ++++++ .../skills/job-application/SKILL.md | 10 ++++++- .../skills/executive-summary/SKILL.md | 21 ++++++++++----- .../pm-cross/skills/grant-proposal/SKILL.md | 8 ++++++ .../skills/last-30-days-research/SKILL.md | 10 ++++++- .../skills/notebooklm-connector/SKILL.md | 10 ++++++- .../pm-cross/skills/press-release/SKILL.md | 8 ++++++ .../skills/sycophancy-challenger/SKILL.md | 10 ++++++- .../skills/teaching-lesson-plan/SKILL.md | 8 ++++++ plugins/pm-cs/skills/churn-analysis/SKILL.md | 10 ++++++- .../pm-cs/skills/cs-escalation-brief/SKILL.md | 8 ++++++ .../pm-cs/skills/cs-health-scorecard/SKILL.md | 8 ++++++ .../skills/customer-success-plan/SKILL.md | 8 ++++++ plugins/pm-cs/skills/qbr-deck/SKILL.md | 8 ++++++ .../pm-cs/skills/renewal-playbook/SKILL.md | 8 ++++++ .../skills/chart-data-extractor/SKILL.md | 7 +++++ .../pm-data/skills/cohort-analysis/SKILL.md | 8 ++++++ .../pm-data/skills/dashboard-brief/SKILL.md | 8 ++++++ .../skills/data-pipeline-spec/SKILL.md | 8 ++++++ .../pm-data/skills/metrics-framework/SKILL.md | 8 ++++++ .../skills/sql-query-explainer/SKILL.md | 2 +- .../skills/ab-test-planner/SKILL.md | 8 ++++++ .../skills/go-to-market-planner/SKILL.md | 8 ++++++ .../skills/pptx-slide-auditor/SKILL.md | 8 ++++++ .../skills/product-launch-checklist/SKILL.md | 17 ++++++++++++ .../skills/retro-analysis/SKILL.md | 10 ++++++- .../pm-delivery/skills/sprint-brief/SKILL.md | 8 ++++++ .../skills/sprint-planning/SKILL.md | 10 ++++++- .../skills/technical-spec-template/SKILL.md | 8 ++++++ .../skills/user-story-writer/SKILL.md | 8 ++++++ .../skills/accessibility-audit/SKILL.md | 8 ++++++ .../pm-design/skills/design-critique/SKILL.md | 10 ++++++- .../skills/design-system-audit/SKILL.md | 8 ++++++ .../skills/ux-research-plan/SKILL.md | 8 ++++++ .../skills/assumption-mapper/SKILL.md | 7 +++++ .../skills/customer-journey-map/SKILL.md | 8 ++++++ .../skills/discovery-interview-guide/SKILL.md | 8 ++++++ .../skills/job-story-mapper/SKILL.md | 16 ++++++++++++ .../skills/user-interview-synthesis/SKILL.md | 10 ++++++- .../skills/api-docs-writer/SKILL.md | 8 ++++++ .../skills/api-versioning-strategy/SKILL.md | 8 ++++++ .../architecture-decision-record/SKILL.md | 8 ++++++ .../skills/capacity-planning/SKILL.md | 8 ++++++ .../skills/changelog-generator/SKILL.md | 8 ++++++ .../skills/cicd-playbook/SKILL.md | 8 ++++++ .../skills/claude-superpowers/SKILL.md | 10 ++++++- .../skills/code-review-checklist/SKILL.md | 8 ++++++ .../skills/context-mode/SKILL.md | 2 +- .../skills/database-migration-plan/SKILL.md | 8 ++++++ .../skills/database-schema-design/SKILL.md | 8 ++++++ .../skills/debugging-log-analyser/SKILL.md | 2 +- .../skills/dependency-audit/SKILL.md | 10 ++++++- .../skills/developer-onboarding-doc/SKILL.md | 8 ++++++ .../skills/disaster-recovery-plan/SKILL.md | 8 ++++++ .../skills/engineering-hiring-rubric/SKILL.md | 8 ++++++ .../skills/engineering-weekly-report/SKILL.md | 8 ++++++ .../skills/feature-flag-guide/SKILL.md | 8 ++++++ .../skills/incident-postmortem/SKILL.md | 8 ++++++ .../skills/infra-as-code-review/SKILL.md | 8 ++++++ .../skills/load-testing-plan/SKILL.md | 8 ++++++ .../skills/local-dev-setup/SKILL.md | 8 ++++++ .../microservices-decomposition/SKILL.md | 8 ++++++ .../skills/monitoring-setup-guide/SKILL.md | 8 ++++++ .../skills/oncall-runbook/SKILL.md | 8 ++++++ .../skills/performance-budget/SKILL.md | 8 ++++++ .../skills/pr-description-writer/SKILL.md | 8 ++++++ .../pm-engineering/skills/rfc-writer/SKILL.md | 8 ++++++ .../skills/runbook-writer/SKILL.md | 8 ++++++ .../skills/security-threat-model/SKILL.md | 8 ++++++ .../skills/service-catalog-entry/SKILL.md | 8 ++++++ .../skills/slo-error-budget/SKILL.md | 8 ++++++ .../skills/sprint-velocity-analysis/SKILL.md | 8 ++++++ .../skills/system-design-interview/SKILL.md | 8 ++++++ .../pm-engineering/skills/tech-radar/SKILL.md | 8 ++++++ .../skills/technical-debt-register/SKILL.md | 8 ++++++ .../skills/test-strategy-doc/SKILL.md | 8 ++++++ .../skills/competitive-analysis/SKILL.md | 7 +++++ .../skills/docx-tracked-changes/SKILL.md | 8 ++++++ .../skills/meeting-notes/SKILL.md | 16 ++++++++++++ .../skills/prd-template/SKILL.md | 8 ++++++ .../skills/stakeholder-update/SKILL.md | 8 ++++++ .../skills/user-research-synthesis/SKILL.md | 26 +++++++++---------- .../skills/figma-annotation-guide/SKILL.md | 8 ++++++ .../skills/figma-component-audit/SKILL.md | 8 ++++++ .../skills/figma-design-brief/SKILL.md | 8 ++++++ .../skills/figma-design-critique-pm/SKILL.md | 10 ++++++- .../pm-figma/skills/figma-design-qa/SKILL.md | 10 ++++++- .../skills/figma-design-review/SKILL.md | 10 ++++++- .../skills/figma-prototype-plan/SKILL.md | 8 ++++++ .../skills/figma-spacing-system/SKILL.md | 8 ++++++ .../skills/figma-user-flow-planner/SKILL.md | 8 ++++++ .../skills/figma-variant-matrix/SKILL.md | 8 ++++++ .../skills/budget-variance-analysis/SKILL.md | 15 ++++++++--- .../skills/financial-due-diligence/SKILL.md | 16 ++++++++++++ .../skills/financial-model-narrative/SKILL.md | 8 ++++++ .../skills/investor-pitch-deck/SKILL.md | 8 ++++++ .../skills/tax-planning-checklist/SKILL.md | 8 ++++++ .../skills/competitor-teardown/SKILL.md | 7 +++++ .../pm-gtm/skills/content-calendar/SKILL.md | 8 ++++++ plugins/pm-gtm/skills/email-campaign/SKILL.md | 8 ++++++ plugins/pm-gtm/skills/go-to-market/SKILL.md | 8 ++++++ plugins/pm-gtm/skills/media-pitch/SKILL.md | 8 ++++++ .../skills/product-positioning-doc/SKILL.md | 8 ++++++ .../pm-gtm/skills/seo-content-brief/SKILL.md | 8 ++++++ .../skills/social-media-strategy/SKILL.md | 8 ++++++ .../skills/change-management-plan/SKILL.md | 8 ++++++ .../employee-engagement-survey/SKILL.md | 20 ++++++++++++++ .../skills/job-description-writer/SKILL.md | 8 ++++++ plugins/pm-hr/skills/onboarding-plan/SKILL.md | 8 ++++++ .../skills/redundancy-consultation/SKILL.md | 8 ++++++ .../skills/compliance-checklist/SKILL.md | 8 ++++++ .../pm-legal/skills/contract-review/SKILL.md | 8 ++++++ plugins/pm-legal/skills/legal-brief/SKILL.md | 8 ++++++ plugins/pm-legal/skills/nda-analyser/SKILL.md | 10 ++++++- .../skills/email-triage/SKILL.md | 10 ++++++- .../skills/morning-intelligence/SKILL.md | 10 ++++++- .../skills/process-documentation/SKILL.md | 8 ++++++ .../skills/project-status-report/SKILL.md | 8 ++++++ .../pm-operations/skills/raci-matrix/SKILL.md | 8 ++++++ .../skills/risk-register/SKILL.md | 8 ++++++ .../pm-operations/skills/sop-writer/SKILL.md | 8 ++++++ .../skills/vendor-evaluation/SKILL.md | 8 ++++++ .../workshop-facilitation-guide/SKILL.md | 8 ++++++ .../skills/360-feedback-template/SKILL.md | 8 ++++++ .../pm-people/skills/hiring-rubric/SKILL.md | 8 ++++++ .../skills/performance-review/SKILL.md | 8 ++++++ .../skills/team-health-check/SKILL.md | 10 ++++++- .../skills/team-offsite-planner/SKILL.md | 8 ++++++ .../skills/feature-prioritisation/SKILL.md | 8 ++++++ .../pm-planning/skills/okr-builder/SKILL.md | 8 ++++++ .../skills/pricing-strategy/SKILL.md | 8 ++++++ .../skills/rice-impact-matrix/SKILL.md | 10 ++++++- .../skills/rice-prioritisation/SKILL.md | 10 ++++++- .../skills/roadmap-narrative/SKILL.md | 8 ++++++ .../skills/roadmap-presentation/SKILL.md | 8 ++++++ .../skills/clinical-case-summary/SKILL.md | 15 ++++++++--- .../skills/literature-review/SKILL.md | 8 ++++++ .../skills/patient-communication/SKILL.md | 8 ++++++ .../skills/research-protocol/SKILL.md | 8 ++++++ .../skills/pm-weekly-review/SKILL.md | 8 ++++++ plugins/pm-sales/skills/account-plan/SKILL.md | 7 +++++ .../skills/discovery-call-prep/SKILL.md | 8 ++++++ .../skills/partnership-proposal/SKILL.md | 8 ++++++ .../pm-sales/skills/proposal-writer/SKILL.md | 8 ++++++ .../pm-sales/skills/sales-battlecard/SKILL.md | 8 ++++++ .../skills/sales-forecasting-model/SKILL.md | 8 ++++++ .../community-management-playbook/SKILL.md | 8 ++++++ .../skills/influencer-brief/SKILL.md | 8 ++++++ .../skills/social-ad-campaign/SKILL.md | 8 ++++++ .../skills/social-media-audit/SKILL.md | 8 ++++++ .../skills/viral-content-framework/SKILL.md | 8 ++++++ .../skills/ambiguity-resolver/SKILL.md | 7 +++++ .../competitive-intelligence-monitor/SKILL.md | 7 +++++ .../skills/competitor-signal-tracker/SKILL.md | 9 ++++++- .../skills/executive-update/SKILL.md | 8 ++++++ .../stakeholder-influence-mapper/SKILL.md | 8 ++++++ .../strategic-narrative-generator/SKILL.md | 8 ++++++ .../pm-writers/skills/aeo-optimizer/SKILL.md | 8 ++++++ .../skills/instagram-post-downloader/SKILL.md | 10 ++++++- .../skills/notes-humanizer/SKILL.md | 10 ++++++- .../skills/substack-notes-scraper/SKILL.md | 10 ++++++- .../skills/thumbnail-creator/SKILL.md | 8 ++++++ 171 files changed, 1428 insertions(+), 56 deletions(-) diff --git a/plugins/pm-advanced/skills/ai-ethics-review/SKILL.md b/plugins/pm-advanced/skills/ai-ethics-review/SKILL.md index 3d7f647..a0c2097 100644 --- a/plugins/pm-advanced/skills/ai-ethics-review/SKILL.md +++ b/plugins/pm-advanced/skills/ai-ethics-review/SKILL.md @@ -1,6 +1,6 @@ --- name: ai-ethics-review -description: "Conduct an ethical review of an AI or ML feature, model, or product. Use when asked to run an AI ethics review, assess AI risks, audit a model for bias, or produce an AI impact assessment. Produces a structured ethics review covering fairness, transparency, privacy, safety, accountability, and societal impact with prioritised mitigations." +description: "Conduct a structured ethical review of an AI or ML feature, model, or product. Use when preparing to deploy an AI system, assessing algorithmic risk, auditing a model for bias, or producing a responsible AI impact assessment. Produces a structured ethics review covering fairness, transparency, privacy, safety, accountability, and societal impact with a risk tier score, pre-deployment checklist, and prioritised mitigations." --- # AI Ethics Review Skill @@ -198,6 +198,14 @@ Ask the user for these if not provided: - [ ] Accountability section names real people, not teams or roles - [ ] Mitigations are specific and time-bound — not "monitor and review" +## Anti-Patterns + +- [ ] Do not limit the affected-population analysis to users of the product — AI that makes decisions about people (hiring, credit, content moderation) affects non-users who have no opt-out +- [ ] Do not accept "we will monitor" as a mitigation without specifying what is monitored, at what threshold, and who acts +- [ ] Do not assign fairness analysis to the model team alone — protected characteristic analysis requires input from legal, HR, or a subject-matter expert +- [ ] Do not defer the DPIA to post-launch — for high-risk tier systems, a DPIA is a pre-requisite for lawful deployment under GDPR +- [ ] Do not conflate statistical accuracy with fairness — a model can be 95% accurate overall while performing significantly worse for a protected group + ## Example Trigger Phrases - "Run an AI ethics review for [feature]" diff --git a/plugins/pm-advanced/skills/ai-product-canvas/SKILL.md b/plugins/pm-advanced/skills/ai-product-canvas/SKILL.md index 913223e..dec64f6 100644 --- a/plugins/pm-advanced/skills/ai-product-canvas/SKILL.md +++ b/plugins/pm-advanced/skills/ai-product-canvas/SKILL.md @@ -152,6 +152,14 @@ Ask the user for these if not provided: - **Available data** (what training/inference data exists) - **ML/AI lead** (who owns the technical implementation) +## Anti-Patterns + +- [ ] Do not skip the "Why AI?" question — if the answer is "we want to use AI," stop and reframe around the user problem first +- [ ] Do not launch with an undefined accuracy threshold — "good enough" is not a threshold; set a number before build begins +- [ ] Do not design the UX to hide AI-generated output as if it were system truth — users need to know when AI is involved so they can override it +- [ ] Do not defer the Responsible AI checklist to post-launch — bias and privacy issues are far harder to fix in production than in design +- [ ] Do not treat model latency as a post-launch optimisation — a 6-second AI response that replaces a 1-second rule-based response is a regression, not a feature + ## Quality Checks - [ ] "Why AI?" is answered clearly (not "because we can") diff --git a/plugins/pm-advanced/skills/design-handoff-brief/SKILL.md b/plugins/pm-advanced/skills/design-handoff-brief/SKILL.md index a7742ca..6513406 100644 --- a/plugins/pm-advanced/skills/design-handoff-brief/SKILL.md +++ b/plugins/pm-advanced/skills/design-handoff-brief/SKILL.md @@ -73,3 +73,11 @@ Ask the user for these if not provided: - [ ] Success criteria are measurable or observable (not "looks good") - [ ] Out-of-scope section names at least one thing that might seem in scope but isn't - [ ] Technical constraints are specific enough for an engineer to confirm + +## Anti-Patterns + +- [ ] Do not write the user goal in feature language ("design the checkout flow") — it must be written from the user's perspective with a motivation and outcome +- [ ] Do not skip the "Explicitly Out of Scope" section — without it, designers will inadvertently solve problems not intended for this iteration +- [ ] Do not list edge cases that are so generic they apply to any feature (e.g. "handle errors") — each edge case must be specific to this feature's failure modes +- [ ] Do not hand off the brief without confirming engineering constraints are accurate — a constraint that is wrong is worse than no constraint +- [ ] Do not omit the emotional context of the user — designs without emotional grounding produce technically correct but experientially flat results diff --git a/plugins/pm-advanced/skills/experiment-designer/SKILL.md b/plugins/pm-advanced/skills/experiment-designer/SKILL.md index 60e646a..b64efc7 100644 --- a/plugins/pm-advanced/skills/experiment-designer/SKILL.md +++ b/plugins/pm-advanced/skills/experiment-designer/SKILL.md @@ -67,3 +67,11 @@ Ask the user for these if not provided: - [ ] Test was not stopped early (or flagged clearly if it was) - [ ] Practical significance assessed separately from statistical significance - [ ] Sample ratio mismatch is checked in results interpretation + +## Anti-Patterns + +- [ ] Do not define success criteria after seeing preliminary results — post-hoc success definitions are HARKing (Hypothesising After Results are Known) and invalidate the experiment +- [ ] Do not stop a test early because the result looks significant — early stopping dramatically inflates false positive rates; the test must run to the planned sample size +- [ ] Do not treat statistical significance as the same as practical significance — a p < 0.05 result with a 0.1% lift is real but may not be worth shipping +- [ ] Do not run the same experiment on the same population multiple times without correction — multiple testing inflates the chance of a false positive proportionally +- [ ] Do not use more than one primary metric — multiple primary metrics require multiple hypothesis corrections and make the ship/kill decision ambiguous diff --git a/plugins/pm-advanced/skills/multi-source-signal-synthesiser/SKILL.md b/plugins/pm-advanced/skills/multi-source-signal-synthesiser/SKILL.md index 33894e0..ac6a100 100644 --- a/plugins/pm-advanced/skills/multi-source-signal-synthesiser/SKILL.md +++ b/plugins/pm-advanced/skills/multi-source-signal-synthesiser/SKILL.md @@ -1,6 +1,6 @@ --- name: multi-source-signal-synthesiser -description: "Synthesise user signals from multiple research sources into a unified insight brief, reconciling conflicting feedback. Use when asked to make sense of data from multiple sources, synthesise user research, reconcile conflicting feedback, or when the user says 'what are users really telling us' or 'make sense of all this user data'. Produces ranked insights with confidence ratings, divergent signal analysis, and research gap identification." +description: "Synthesises user signals from multiple research sources into a unified, weighted insight brief. Use when you have data from interviews, support tickets, NPS verbatims, app reviews, or sales calls and need to reconcile contradictions, surface the underlying need behind requests, or answer 'what are users really telling us'. Produces ranked insights with confidence ratings, source weighting rationale, divergent signal analysis by user segment, and a research gap identification section." --- # Multi-Source Signal Synthesiser Skill @@ -60,3 +60,11 @@ Ask the user for these if not provided: - [ ] Divergent signals identify the specific user segments, not just "some users disagree" - [ ] Confidence ratings are consistent with source diversity and weighting - [ ] "What the data does NOT tell us" section is honest about gaps + +## Anti-Patterns + +- [ ] Do not echo surface-level feature requests as insights — translate every request to the underlying need before including it as a finding +- [ ] Do not assign High confidence to insights supported by only one source type — confidence requires corroboration across at least two distinct source types +- [ ] Do not treat all sources as equally weighted — a single interview quote and a pattern across 200 support tickets are not comparable signals +- [ ] Do not collapse divergent signals into a single finding — where user segments have genuinely different needs, name the segments explicitly rather than averaging them away +- [ ] Do not omit the research gap section when key decisions rest on thin data — acting on low-confidence findings without flagging the gaps misleads product teams diff --git a/plugins/pm-analytics/skills/data-analysis-standard/SKILL.md b/plugins/pm-analytics/skills/data-analysis-standard/SKILL.md index 6f42515..9d054f3 100644 --- a/plugins/pm-analytics/skills/data-analysis-standard/SKILL.md +++ b/plugins/pm-analytics/skills/data-analysis-standard/SKILL.md @@ -117,6 +117,14 @@ Ask the user for these if not provided: - [ ] What the data cannot tell us is explicitly named - [ ] Recommended action includes an owner and timeline +## Anti-Patterns + +- [ ] Do not present correlations as causation — always state the distinction explicitly +- [ ] Do not report a metric movement without stating the time window and comparison baseline +- [ ] Do not skip the "so what" — raw observations without recommended actions are incomplete analysis +- [ ] Do not overstate confidence — label hypotheses clearly and note what data would be needed to confirm them +- [ ] Do not ignore segment breakdowns — aggregate metrics can mask opposing trends in sub-segments + ## Guidelines - Always state what the data *cannot* tell you — never oversell confidence diff --git a/plugins/pm-analytics/skills/product-health-analysis/SKILL.md b/plugins/pm-analytics/skills/product-health-analysis/SKILL.md index 32aaa2a..9c58a08 100644 --- a/plugins/pm-analytics/skills/product-health-analysis/SKILL.md +++ b/plugins/pm-analytics/skills/product-health-analysis/SKILL.md @@ -57,3 +57,11 @@ Analyse across four layers: - [ ] Every flagged metric has a root cause hypothesis, not just "it dropped" - [ ] Observations are written for a non-technical stakeholder (no raw query language or data jargon) - [ ] Overall health rating is justified with specific evidence + +## Anti-Patterns + +- [ ] Do not report a single aggregate metric without segment breakdowns — averages hide opposing trends +- [ ] Do not flag a metric as healthy just because it is above the target — check if the target itself is meaningful +- [ ] Do not list metric movements without root cause hypotheses — observations without explanations are not analysis +- [ ] Do not mix product health metrics with business KPIs without explaining the relationship between them +- [ ] Do not omit recommended actions — a health report that only describes problems without prioritised next steps is incomplete diff --git a/plugins/pm-analytics/skills/retention-analysis/SKILL.md b/plugins/pm-analytics/skills/retention-analysis/SKILL.md index 15c6e32..14a11ce 100644 --- a/plugins/pm-analytics/skills/retention-analysis/SKILL.md +++ b/plugins/pm-analytics/skills/retention-analysis/SKILL.md @@ -126,6 +126,14 @@ Ask the user for these if not provided: - [ ] Churned user interviews are recommended (not just data analysis) - [ ] Monitoring plan includes an alert threshold +## Anti-Patterns + +- [ ] Do not recommend "improve onboarding" without specifying what specific step to change and why +- [ ] Do not analyse retention without segmenting by cohort — aggregate retention curves hide cohort-specific patterns +- [ ] Do not treat DAU/MAU below 5% as a retention problem — at that level, it is a product-market fit problem +- [ ] Do not skip qualitative research — churned user interviews reveal reasons that quantitative data cannot +- [ ] Do not set a monitoring alert without specifying the threshold that triggers it + ## Guidelines - Never recommend "improve onboarding" without specifying *what* to change and *why* diff --git a/plugins/pm-business/skills/board-deck-narrative/SKILL.md b/plugins/pm-business/skills/board-deck-narrative/SKILL.md index 59b7473..b31ab63 100644 --- a/plugins/pm-business/skills/board-deck-narrative/SKILL.md +++ b/plugins/pm-business/skills/board-deck-narrative/SKILL.md @@ -149,6 +149,14 @@ Ask the user for these if not provided: - [ ] Board asks are specific and actionable - [ ] Deck is ≤ 15 slides (excluding appendix) +## Anti-Patterns + +- [ ] Do not bury bad news after slides full of good news — boards lose trust when they discover problems were de-emphasised; lead with the honest narrative +- [ ] Do not include slides without a "so what" — a chart that shows data without a takeaway wastes board time and signals the presenter hasn't done the analysis +- [ ] Do not exceed 15 slides in the main deck — a longer deck usually means the presenter hasn't decided what matters most +- [ ] Do not attend a board meeting without at least one specific ask — a board meeting with no asks is a missed opportunity to leverage the room +- [ ] Do not report metrics without comparing them to plan or a prior period — a metric shown in isolation gives the board no basis for judgement + ## Example Trigger Phrases - "Build a board deck structure for our Q[N] board meeting" diff --git a/plugins/pm-business/skills/investor-update/SKILL.md b/plugins/pm-business/skills/investor-update/SKILL.md index 49e0348..8537f75 100644 --- a/plugins/pm-business/skills/investor-update/SKILL.md +++ b/plugins/pm-business/skills/investor-update/SKILL.md @@ -119,6 +119,14 @@ Hi [Investor names or "all"], - [ ] Total length is skimmable in 3–4 minutes - [ ] No spin or buzzwords +## Anti-Patterns + +- [ ] Do not omit challenges or bad news — sanitised updates erode investor trust faster than bad results do +- [ ] Do not bury the lead — use BLUF structure and put the most important news in the first paragraph +- [ ] Do not send an update without a clear "Ask" section — investors who want to help need to know how +- [ ] Do not use buzzwords or spin — investors see hundreds of updates and will see through vague positive language +- [ ] Do not report metrics without a comparison baseline — numbers without context (vs. last period or target) are meaningless + ## Example Trigger Phrases - "Write an investor update for [month/quarter]" diff --git a/plugins/pm-business/skills/job-application/SKILL.md b/plugins/pm-business/skills/job-application/SKILL.md index 8dd5d03..a2fbbb5 100644 --- a/plugins/pm-business/skills/job-application/SKILL.md +++ b/plugins/pm-business/skills/job-application/SKILL.md @@ -1,6 +1,6 @@ --- name: job-application -description: "Tailor a CV and cover letter to a specific job description. Use when asked to write a cover letter, tailor a CV or resume, optimise for ATS, match a job description, or prepare a job application. Produces an ATS-optimised tailored CV summary and a personalised cover letter." +description: "Tailors a CV and cover letter to a specific job description. Use when asked to write a cover letter, tailor a CV or resume, optimise for ATS, match a job description, or prepare a job application. Produces an ATS-optimised tailored CV summary and a personalised cover letter aligned to the role's requirements." --- # Job Application Skill @@ -120,6 +120,14 @@ Before submitting: - [ ] Cover letter is 250–350 words - [ ] Gaps are either addressed or strategically omitted +## Anti-Patterns + +- [ ] Do not fabricate or embellish experience — only use real achievements from the provided CV +- [ ] Do not use the same cover letter template for every role — every letter must reference specific details of the job description +- [ ] Do not address selection criteria that aren't in the JD — match keywords the employer actually used +- [ ] Do not omit ATS optimisation — ensure role-specific keywords from the JD appear naturally in the CV summary +- [ ] Do not write a cover letter that re-summarises the CV — it must add context and motivation, not repeat bullet points + ## Example Trigger Phrases - "Help me apply for this job: [paste JD]" diff --git a/plugins/pm-cross/skills/executive-summary/SKILL.md b/plugins/pm-cross/skills/executive-summary/SKILL.md index a4102dc..22f4a9a 100644 --- a/plugins/pm-cross/skills/executive-summary/SKILL.md +++ b/plugins/pm-cross/skills/executive-summary/SKILL.md @@ -84,12 +84,21 @@ An executive summary is NOT a summary of the document. It is a standalone docume **Client:** Lead with their problem. Show you understand before presenting recommendation. ## Quality Checks -- Bottom line in first 3 sentences -- Standalone — no need to read full document -- Recommendation is specific -- Fits length limit -- Written for audience priorities not author priorities -- Next steps have owners and dates + +- [ ] Bottom line in first 3 sentences +- [ ] Standalone — no need to read full document +- [ ] Recommendation is specific +- [ ] Fits length limit +- [ ] Written for audience priorities not author priorities +- [ ] Next steps have owners and dates + +## Anti-Patterns + +- [ ] Do not summarise the document chronologically — an executive summary that follows the structure of the source document is not an executive summary, it is an abstract +- [ ] Do not bury the recommendation at the end — executives read the first paragraph and skim the rest; the ask must be in sentence one or two +- [ ] Do not use the same summary for different audiences — a CEO and a board member have different decision contexts and require different framing +- [ ] Do not include background that the reader already knows — every sentence of background must earn its place by making the bottom line more actionable +- [ ] Do not leave the "risks of inaction" section vague — a summary that does not quantify what happens if the reader does nothing removes the urgency needed for a decision ## Example Trigger Phrases - "Write an executive summary of this report: [paste]" diff --git a/plugins/pm-cross/skills/grant-proposal/SKILL.md b/plugins/pm-cross/skills/grant-proposal/SKILL.md index b4d4ead..6581169 100644 --- a/plugins/pm-cross/skills/grant-proposal/SKILL.md +++ b/plugins/pm-cross/skills/grant-proposal/SKILL.md @@ -96,6 +96,14 @@ Funder test: does this problem align with [funder] stated priorities? Make the c - [ ] Sustainability section explains what happens after the grant ends - [ ] Word limits respected +## Anti-Patterns + +- [ ] Do not write a generic proposal — every section must be tailored to the specific funder's stated priorities +- [ ] Do not exceed the specified word or page limits — over-length proposals are disqualified at many funders +- [ ] Do not leave the sustainability section vague — funders need to know what happens after grant funding ends +- [ ] Do not use jargon the funder's reviewers won't understand — write for the panel, not the project team +- [ ] Do not underspecify the budget narrative — every significant line item must be justified with method and reasoning + ## Example Trigger Phrases - "Write a grant proposal for [project] applying to [funder]" - "Help me write a funding application for [grant programme]" diff --git a/plugins/pm-cross/skills/last-30-days-research/SKILL.md b/plugins/pm-cross/skills/last-30-days-research/SKILL.md index 8f055fe..3092a70 100644 --- a/plugins/pm-cross/skills/last-30-days-research/SKILL.md +++ b/plugins/pm-cross/skills/last-30-days-research/SKILL.md @@ -1,6 +1,6 @@ --- name: last-30-days-research -description: Multi-platform research skill that gathers recent (last 30 days) opinions, sentiment, and signal on any topic from Reddit, X/Twitter, and the web. Cuts through SEO-stuffed results to surface what real people are actually saying. +description: "Searches Reddit, X/Twitter, and the broader web for recent opinions, sentiment, and signal on any topic. Use when you need to know what real people are saying about a tool, product, trend, or event in the past 30 days — cutting through SEO content to surface genuine community reaction. Produces a structured report with consensus findings, pain points, positive signals, contrarian takes, source links, and a signal confidence rating." --- # Last 30 Days Research @@ -138,6 +138,14 @@ Before outputting the report, verify: - [ ] No vendor-authored content or press releases treated as independent signal - [ ] Synonyms and alternative names for the topic were searched +## Anti-Patterns + +- [ ] Do not treat SEO blog posts or vendor-authored content as community signal — only count independent sources +- [ ] Do not report findings without applying the date filter — prior knowledge mixed with recent search results produces stale, unverifiable claims +- [ ] Do not fabricate or guess at URLs — every link in the Sources section must have been retrieved during the research session +- [ ] Do not report a single mention as a "finding" — a finding requires corroboration from at least two independent sources +- [ ] Do not rate Signal Confidence as High when fewer than 5 credible sources were found — this misleads the reader about how much to rely on the output + ## Example Trigger Phrases - "What are people saying about Cursor AI from the last 30 days?" diff --git a/plugins/pm-cross/skills/notebooklm-connector/SKILL.md b/plugins/pm-cross/skills/notebooklm-connector/SKILL.md index ace4ffc..8371326 100644 --- a/plugins/pm-cross/skills/notebooklm-connector/SKILL.md +++ b/plugins/pm-cross/skills/notebooklm-connector/SKILL.md @@ -1,6 +1,6 @@ --- name: notebooklm-connector -description: Automates NotebookLM from Claude Code — creates notebooks, adds sources, and triggers outputs (mindmaps, audio overviews, slide decks) without manual clicking via the Claude Chrome extension. +description: "Automates NotebookLM from Claude Code using browser automation via the Claude Chrome extension — creating notebooks, adding sources, and triggering outputs without manual clicking. Use when you want to create a NotebookLM notebook, add URLs or documents as sources, or generate mindmaps, audio overviews, or briefing docs programmatically. Produces a confirmed checklist of completed actions and a direct link to the notebook." --- # NotebookLM Connector @@ -164,6 +164,14 @@ If any step fails, do the following: - [ ] Manual workaround was offered for any step that failed - [ ] Output checklist accurately reflects what was completed vs. what failed +## Anti-Patterns + +- [ ] Do not proceed with any browser action before the full request has been parsed into discrete steps — ambiguous source references must be clarified before navigating +- [ ] Do not guess at source URLs if the user says "add my research sources" without specifying them — ask for the explicit list before starting +- [ ] Do not batch actions speculatively — each action must be confirmed complete before the next one begins to avoid compounding failures +- [ ] Do not wait for audio overview rendering to complete — audio overviews take 5–15 minutes server-side; report the trigger and move on rather than blocking the session +- [ ] Do not attempt this skill if the Claude Chrome extension is not active — report the missing prerequisite immediately rather than attempting browser steps that will fail + ## Example Trigger Phrases - "Open NotebookLM and create a notebook called 'Competitor Analysis Q2'" diff --git a/plugins/pm-cross/skills/press-release/SKILL.md b/plugins/pm-cross/skills/press-release/SKILL.md index e1c85c5..4f96fe4 100644 --- a/plugins/pm-cross/skills/press-release/SKILL.md +++ b/plugins/pm-cross/skills/press-release/SKILL.md @@ -72,6 +72,14 @@ Would a journalist care? Is the headline the full story? Is there a human angle? - [ ] Boilerplate is factual, not promotional - [ ] Embargo date and media contact are included +## Anti-Patterns + +- [ ] Do not bury the news — the most important information must appear in the first paragraph (inverted pyramid) +- [ ] Do not use promotional language or superlatives — press releases must read as news, not advertising copy +- [ ] Do not omit the boilerplate — every press release needs the standard "About [Company]" paragraph at the end +- [ ] Do not forget the embargo date and media contact — journalists need both to use the release +- [ ] Do not write a headline longer than 12 words — it must be scannable and specific + ## Example Trigger Phrases - "Write a press release announcing [news]" - "Draft a media statement about [event]" diff --git a/plugins/pm-cross/skills/sycophancy-challenger/SKILL.md b/plugins/pm-cross/skills/sycophancy-challenger/SKILL.md index b70a00c..505a9d5 100644 --- a/plugins/pm-cross/skills/sycophancy-challenger/SKILL.md +++ b/plugins/pm-cross/skills/sycophancy-challenger/SKILL.md @@ -1,6 +1,6 @@ --- name: sycophancy-challenger -description: Flips Claude's default from "find reasons you're right" to "find reasons you're wrong." A genuine thinking partner, not a mirror with grammar. Use before high-stakes decisions, plans, assumptions, or pitches you haven't stress-tested. +description: "Flips Claude's default from validation to adversarial critique. Use before high-stakes decisions, plans, assumptions, or pitches you haven't stress-tested. Produces structured challenges, steelmanned counter-arguments, and the strongest case against your position — a genuine thinking partner, not a mirror." --- # Sycophancy Challenger @@ -143,6 +143,14 @@ These prohibitions do more work than the rules above. Follow them absolutely: --- +## Anti-Patterns + +- [ ] Do not open with a softening phrase or acknowledgment before the challenge — the first sentence must be the critique +- [ ] Do not retreat from a position when the user pushes back without providing new evidence — update only when genuinely persuaded +- [ ] Do not invent flaws — every criticism must connect to something real in what the user described +- [ ] Do not provide a list of weak objections — identify the single strongest case against the idea +- [ ] Do not end the session because the user seems satisfied — end only when something genuinely changed or was defended + ## Example Trigger Phrases - "Use the sycophancy-challenger skill — here's my plan: [describe it]" diff --git a/plugins/pm-cross/skills/teaching-lesson-plan/SKILL.md b/plugins/pm-cross/skills/teaching-lesson-plan/SKILL.md index 23d6cf5..bd7c4fe 100644 --- a/plugins/pm-cross/skills/teaching-lesson-plan/SKILL.md +++ b/plugins/pm-cross/skills/teaching-lesson-plan/SKILL.md @@ -110,6 +110,14 @@ By the end of this session, participants will be able to: - [ ] Differentiation is specified for both support and extension - [ ] Timing adds up to session length +## Anti-Patterns + +- [ ] Do not design a lesson plan without explicitly stating the learning objectives — activities must trace back to outcomes +- [ ] Do not allocate timing that does not add up to the total session length — the plan must be time-feasible +- [ ] Do not create activities with no assessment component — learning must be measurable, not just delivered +- [ ] Do not ignore differentiation — a plan with no accommodation for different learning levels or abilities is incomplete +- [ ] Do not front-load all content delivery without interactive breaks — passive listening degrades retention after 15–20 minutes + ## Example Trigger Phrases - "Write a lesson plan on [topic] for [audience]" diff --git a/plugins/pm-cs/skills/churn-analysis/SKILL.md b/plugins/pm-cs/skills/churn-analysis/SKILL.md index f7bcf17..061999c 100644 --- a/plugins/pm-cs/skills/churn-analysis/SKILL.md +++ b/plugins/pm-cs/skills/churn-analysis/SKILL.md @@ -1,6 +1,6 @@ --- name: churn-analysis -description: "Analyse customer churn for a product or cohort and produce a structured churn report. Use when asked to analyse churn, understand why customers are leaving, identify churn patterns, calculate churn rate, or build a churn reduction plan. Produces a churn analysis with rate calculations, categorised reasons, early warning signals, and prioritised interventions." +description: "Produce a structured churn analysis that separates avoidable from unavoidable churn. Use when investigating why customers are leaving, identifying at-risk segments, calculating net revenue retention, or building a retention intervention plan. Produces a churn report with rate calculations, categorised reasons by avoidability, segment breakdown, timing analysis, early warning signals, and prioritised interventions ranked by estimated impact." --- # Churn Analysis Skill @@ -169,6 +169,14 @@ Ranked by estimated impact × feasibility. --- +## Anti-Patterns + +- [ ] Do not mix avoidable and unavoidable churn in intervention plans — recommending product fixes for customers who churned due to company shutdown wastes resources +- [ ] Do not calculate churn rate using end-of-period customer count as the denominator — this understates churn; always divide churned customers by the starting cohort +- [ ] Do not rely solely on exit survey data for churn reasons — response rates are typically low and self-selection biases the sample toward customers who are engaged enough to complete a survey +- [ ] Do not recommend interventions without linking them to a specific churn reason — interventions disconnected from root causes will not move retention +- [ ] Do not report only gross revenue churn — without net revenue retention (NRR), a healthy-looking retention number can hide a shrinking revenue base + ## Quality Checks - [ ] Churn rate is correctly calculated (churned ÷ starting cohort, not end-of-period total) diff --git a/plugins/pm-cs/skills/cs-escalation-brief/SKILL.md b/plugins/pm-cs/skills/cs-escalation-brief/SKILL.md index 0cca77d..31a6690 100644 --- a/plugins/pm-cs/skills/cs-escalation-brief/SKILL.md +++ b/plugins/pm-cs/skills/cs-escalation-brief/SKILL.md @@ -174,3 +174,11 @@ Include: - [ ] ARR at risk is quantified - [ ] Communication plan has owners and dates — not "TBD" - [ ] Language is professional and blameless toward individuals + +## Anti-Patterns + +- [ ] Do not assign blame to individuals — focus on system failures and process gaps +- [ ] Do not downplay ARR at risk or describe churn risk vaguely without a number +- [ ] Do not leave resolution plan ownership as "TBD" or unassigned +- [ ] Do not write the brief without a clear ask from the escalation owner +- [ ] Do not omit the customer's own stated position — their perspective must be represented fairly diff --git a/plugins/pm-cs/skills/cs-health-scorecard/SKILL.md b/plugins/pm-cs/skills/cs-health-scorecard/SKILL.md index 17237b7..32a080e 100644 --- a/plugins/pm-cs/skills/cs-health-scorecard/SKILL.md +++ b/plugins/pm-cs/skills/cs-health-scorecard/SKILL.md @@ -139,3 +139,11 @@ Score each dimension 1–5. Weight as shown. Calculate weighted total out of 100 - [ ] Actions have owners and deadlines - [ ] Renewal probability is calibrated against pipeline reality - [ ] Trend arrows reflect direction of change vs. last scorecard, not just current state + +## Anti-Patterns + +- [ ] Do not score health dimensions on gut feel — every score needs specific supporting evidence +- [ ] Do not give a Green status to accounts with unresolved P1 issues or missed milestones +- [ ] Do not list risks vaguely — "low engagement" without specifics is not actionable +- [ ] Do not leave recommended actions without named owners and deadlines +- [ ] Do not conflate product usage frequency with product value delivery diff --git a/plugins/pm-cs/skills/customer-success-plan/SKILL.md b/plugins/pm-cs/skills/customer-success-plan/SKILL.md index 55a966f..ef6e778 100644 --- a/plugins/pm-cs/skills/customer-success-plan/SKILL.md +++ b/plugins/pm-cs/skills/customer-success-plan/SKILL.md @@ -183,6 +183,14 @@ If the success plan falls off track: - [ ] Plan is written to be shared with the customer — no internal-only commentary in this document - [ ] Executive sponsor is identified and has an engagement role +## Anti-Patterns + +- [ ] Do not define success metrics that the vendor controls — metrics must reflect the customer's business outcomes +- [ ] Do not set milestone dates without customer confirmation — unilateral timelines undermine joint ownership +- [ ] Do not create a plan the customer hasn't agreed to — it must be mutual, not a CSM's internal plan +- [ ] Do not leave ownership fields blank or assigned to "CS team" — every action needs a named owner +- [ ] Do not confuse product adoption milestones with customer business outcomes — both are needed but are not the same + ## Example Trigger Phrases - "Build a success plan for [Account Name] who just signed" diff --git a/plugins/pm-cs/skills/qbr-deck/SKILL.md b/plugins/pm-cs/skills/qbr-deck/SKILL.md index 0c5ea5e..b747ccb 100644 --- a/plugins/pm-cs/skills/qbr-deck/SKILL.md +++ b/plugins/pm-cs/skills/qbr-deck/SKILL.md @@ -216,3 +216,11 @@ Prompt questions: - [ ] Roadmap preview links each item to a customer goal - [ ] Mutual commitments section has real owners on both sides - [ ] Customer has at least 20 minutes of airtime in the agenda + +## Anti-Patterns + +- [ ] Do not fill the QBR with product activity metrics — lead with business outcomes the customer cares about +- [ ] Do not present a roadmap without linking each item to a customer goal — vendor priorities are not a QBR agenda +- [ ] Do not run a QBR as a one-sided presentation — it must include structured time for the customer to speak +- [ ] Do not close a QBR without documented mutual commitments with named owners on both sides +- [ ] Do not skip the "what's not working" slide — suppressing problems erodes trust and misses renewal risks diff --git a/plugins/pm-cs/skills/renewal-playbook/SKILL.md b/plugins/pm-cs/skills/renewal-playbook/SKILL.md index 8828e81..32b9dc2 100644 --- a/plugins/pm-cs/skills/renewal-playbook/SKILL.md +++ b/plugins/pm-cs/skills/renewal-playbook/SKILL.md @@ -181,6 +181,14 @@ Prepare for the most likely objections: - [ ] Timeline starts at least 90 days before renewal date - [ ] Objection responses are specific to this account, not generic +## Anti-Patterns + +- [ ] Do not start renewal conversations less than 90 days before the renewal date for accounts over $50K ARR +- [ ] Do not build a renewal strategy without first honestly assessing account health — wishful thinking leads to last-minute churn +- [ ] Do not treat all renewal objections as negotiating tactics — some objections signal genuine dissatisfaction that requires resolution first +- [ ] Do not offer discounts as the first response to price objections — explore value gaps before reducing price +- [ ] Do not close the renewal without confirming the expansion opportunity — every renewal is also an expansion conversation + ## Example Trigger Phrases - "Build a renewal playbook for [Account Name] renewing in [Month]" diff --git a/plugins/pm-data/skills/chart-data-extractor/SKILL.md b/plugins/pm-data/skills/chart-data-extractor/SKILL.md index 556b527..c1e50fd 100644 --- a/plugins/pm-data/skills/chart-data-extractor/SKILL.md +++ b/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" diff --git a/plugins/pm-data/skills/cohort-analysis/SKILL.md b/plugins/pm-data/skills/cohort-analysis/SKILL.md index f2c87ca..856cbde 100644 --- a/plugins/pm-data/skills/cohort-analysis/SKILL.md +++ b/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" diff --git a/plugins/pm-data/skills/dashboard-brief/SKILL.md b/plugins/pm-data/skills/dashboard-brief/SKILL.md index 094972e..c8584bc 100644 --- a/plugins/pm-data/skills/dashboard-brief/SKILL.md +++ b/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]" diff --git a/plugins/pm-data/skills/data-pipeline-spec/SKILL.md b/plugins/pm-data/skills/data-pipeline-spec/SKILL.md index d1776bc..0bbb907 100644 --- a/plugins/pm-data/skills/data-pipeline-spec/SKILL.md +++ b/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" diff --git a/plugins/pm-data/skills/metrics-framework/SKILL.md b/plugins/pm-data/skills/metrics-framework/SKILL.md index b266a9a..6476520 100644 --- a/plugins/pm-data/skills/metrics-framework/SKILL.md +++ b/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]" diff --git a/plugins/pm-data/skills/sql-query-explainer/SKILL.md b/plugins/pm-data/skills/sql-query-explainer/SKILL.md index d13edd8..1f39864 100644 --- a/plugins/pm-data/skills/sql-query-explainer/SKILL.md +++ b/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 diff --git a/plugins/pm-delivery/skills/ab-test-planner/SKILL.md b/plugins/pm-delivery/skills/ab-test-planner/SKILL.md index 239d07e..3917900 100644 --- a/plugins/pm-delivery/skills/ab-test-planner/SKILL.md +++ b/plugins/pm-delivery/skills/ab-test-planner/SKILL.md @@ -103,6 +103,14 @@ Flag if traffic is too low to reach significance in under 8 weeks — recommend - If traffic is very low (<1,000 users/day), recommend qualitative alternatives: moderated testing, 5-second tests, or user interviews - Never approve a test with no guardrail metrics — always protect revenue, retention, or core engagement +## Anti-Patterns + +- [ ] Do not run a test without a directional hypothesis — "let's see what happens" produces uninterpretable results +- [ ] Do not declare a winner before reaching the pre-planned sample size — peeking at results inflates false positive rates +- [ ] Do not test multiple independent changes in a single variant — you won't know which change caused the result +- [ ] Do not use engagement metrics (clicks, time-on-page) as the primary metric when the goal is revenue or retention — proxy metrics mislead +- [ ] Do not ignore guardrail metrics — a conversion lift that causes a support ticket spike is not a win + ## Quality Checks - [ ] Hypothesis is directional (predicts a specific direction and magnitude, not "let's see") diff --git a/plugins/pm-delivery/skills/go-to-market-planner/SKILL.md b/plugins/pm-delivery/skills/go-to-market-planner/SKILL.md index 478d993..109ff8c 100644 --- a/plugins/pm-delivery/skills/go-to-market-planner/SKILL.md +++ b/plugins/pm-delivery/skills/go-to-market-planner/SKILL.md @@ -131,3 +131,11 @@ Ask the user for these if not provided: - [ ] Success metrics include a measurement window (30/60/90 days) - [ ] Rollback procedure is confirmed for Tier 1 and 2 launches - [ ] Post-launch retrospective is scheduled + +## Anti-Patterns + +- [ ] Do not build a Tier 1 GTM plan for an incremental feature update — tier the launch appropriately before planning +- [ ] Do not create activity lists without named owners and due dates — unowned tasks do not get done +- [ ] Do not skip the rollback procedure for Tier 1 and 2 launches — every significant launch must have an abort plan +- [ ] Do not treat marketing and engineering as separate tracks — cross-functional coordination is the whole point of a GTM plan +- [ ] Do not set success metrics without a defined measurement window — "increase signups" is not a measurable target diff --git a/plugins/pm-delivery/skills/pptx-slide-auditor/SKILL.md b/plugins/pm-delivery/skills/pptx-slide-auditor/SKILL.md index 53586bf..4f87066 100644 --- a/plugins/pm-delivery/skills/pptx-slide-auditor/SKILL.md +++ b/plugins/pm-delivery/skills/pptx-slide-auditor/SKILL.md @@ -82,6 +82,14 @@ Order by: fixes before handoff (critical) > consistency fixes (high) > polish (m - [ ] Audience-appropriate concerns flagged explicitly - [ ] Slides without issues are listed briefly, not ignored +## Anti-Patterns + +- [ ] Do not flag stylistic preferences as issues — only report genuine layout problems, overflow, and consistency errors +- [ ] Do not produce a flat list of issues — group by severity (Critical / Major / Minor) so fixes can be prioritised +- [ ] Do not skip slides without commenting — every slide must have an explicit pass or issue status +- [ ] Do not suggest redesigning content — the audit scope is layout, consistency, and readability, not messaging +- [ ] Do not report the same issue type repeatedly across slides without summarising the pattern — consolidate repeated issues + ## Example Trigger Phrases - "Audit this slide deck before my board meeting" - "Review this PowerPoint for layout issues" diff --git a/plugins/pm-delivery/skills/product-launch-checklist/SKILL.md b/plugins/pm-delivery/skills/product-launch-checklist/SKILL.md index 0741653..e07d6e4 100644 --- a/plugins/pm-delivery/skills/product-launch-checklist/SKILL.md +++ b/plugins/pm-delivery/skills/product-launch-checklist/SKILL.md @@ -7,6 +7,15 @@ description: "Generate a comprehensive pre-launch, launch day, and post-launch c Never launch without checking everything. Generate a complete, role-assigned checklist covering pre-launch readiness, launch day execution, and post-launch monitoring. +## Required Inputs + +Ask the user for these if not provided: +- **Launch name** and planned launch date +- **Launch tier** (1 = major product launch, 2 = significant feature release, 3 = incremental update) +- **Team members and their roles** (engineering lead, PM, marketing, support, etc.) +- **Feature description** (what is being launched) +- **Rollback capability** (can this be feature-flagged or reverted quickly?) + ## How to Use This Skill Provide: @@ -117,6 +126,14 @@ The skill generates a tiered checklist. Tier 3 launches use only the Essentials - [ ] Feature flag expansion is staged (5% → 50% → 100%), not all-at-once - [ ] Post-launch retrospective is scheduled at launch time +## Anti-Patterns + +- [ ] Do not apply a Tier 1 checklist to an incremental update — tier the launch appropriately before generating the checklist +- [ ] Do not launch on a Friday without confirmed weekend engineering coverage +- [ ] Do not leave the Go/No-Go decision owner as "the team" — it must be a named individual +- [ ] Do not skip the rollback plan for Tier 1 and 2 launches — know the revert time before going live +- [ ] Do not close the launch without scheduling the post-launch retrospective — it must be booked at launch time, not after + ## Guidelines - The Go/No-Go decision must have a named owner — "the team" is not an owner diff --git a/plugins/pm-delivery/skills/retro-analysis/SKILL.md b/plugins/pm-delivery/skills/retro-analysis/SKILL.md index 512e545..a92a54d 100644 --- a/plugins/pm-delivery/skills/retro-analysis/SKILL.md +++ b/plugins/pm-delivery/skills/retro-analysis/SKILL.md @@ -1,6 +1,6 @@ --- name: retro-analysis -description: "Analyse sprint delivery data and produce a structured retrospective brief. Use when asked to run a retrospective, analyse sprint data, prepare a retro brief, or turn sprint metrics into discussion prompts. Produces a data-grounded retrospective brief with completion stats, pattern analysis, Start/Stop/Continue prompts, and one concrete experiment for next sprint." +description: "Analyses sprint delivery data and produces a structured retrospective brief. Use when asked to run a retrospective, analyse sprint data, prepare a retro brief, or turn sprint metrics into discussion prompts. Produces a data-grounded retrospective brief with completion stats, pattern analysis, Start/Stop/Continue prompts, and one concrete experiment for next sprint." --- # Retrospective Analysis Skill @@ -51,3 +51,11 @@ Ask the user for these if not provided: - [ ] Carry-over analysis identifies the ticket type or cause, not just the count - [ ] Data observations don't assign blame — they describe patterns - [ ] Velocity trend is mentioned in context (is this a one-off or a pattern?) + +## Anti-Patterns + +- [ ] Do not assign blame to individuals in the retrospective brief — observations must describe patterns, not people +- [ ] Do not produce Start/Stop/Continue prompts that are vague categories — each must name a specific behaviour +- [ ] Do not recommend an experiment that cannot be completed within one sprint — small, testable experiments only +- [ ] Do not treat carry-over tickets as a velocity problem without first identifying the root cause category +- [ ] Do not run the same retrospective format every sprint — vary the format to prevent engagement fatigue diff --git a/plugins/pm-delivery/skills/sprint-brief/SKILL.md b/plugins/pm-delivery/skills/sprint-brief/SKILL.md index acc2ecc..1d20b5d 100644 --- a/plugins/pm-delivery/skills/sprint-brief/SKILL.md +++ b/plugins/pm-delivery/skills/sprint-brief/SKILL.md @@ -51,3 +51,11 @@ Ask the user for these if not provided: - [ ] Every risk has a mitigation or owner (not just "this is a risk") - [ ] Carry-over items are connected to their impact on this sprint's goal - [ ] Definition of Done is agreed criteria, not a task list + +## Anti-Patterns + +- [ ] Do not write a sprint goal as a task list — the goal must be a single outcome-focused statement that can be scored pass/fail +- [ ] Do not leave the critical path unnamed — "the important tickets" is not a critical path +- [ ] Do not list risks without a mitigation or owner — a risk without a response is just a worry list +- [ ] Do not ignore carry-over items' impact on this sprint's capacity and goal +- [ ] Do not write a Definition of Done that mixes task completion with outcome criteria — they must be observable and agreed before the sprint starts diff --git a/plugins/pm-delivery/skills/sprint-planning/SKILL.md b/plugins/pm-delivery/skills/sprint-planning/SKILL.md index dfda5b4..2d62a23 100644 --- a/plugins/pm-delivery/skills/sprint-planning/SKILL.md +++ b/plugins/pm-delivery/skills/sprint-planning/SKILL.md @@ -15,7 +15,7 @@ Transform raw backlog items into a structured, achievable sprint with clear goal - **Sprint Planning Agenda** — structured 2-hour meeting agenda with timings - **Risk Flags** — blockers or dependencies that could derail the sprint -## Inputs to Request From User +## Required Inputs Ask for (if not already provided): - Sprint duration (1 or 2 weeks) @@ -95,3 +95,11 @@ Story points to commit = Historical velocity × Availability factor - [ ] Every story has an acceptance criterion (flag any that don't) - [ ] Stories estimated at 8+ points are flagged for splitting - [ ] Carry-overs from last sprint are accounted for in capacity + +## Anti-Patterns + +- [ ] Do not write sprint goals as task lists — goals must be outcome-focused and scoreable pass/fail at sprint end +- [ ] Do not commit to 100% of available capacity — always recommend 80% to preserve slack for unplanned work +- [ ] Do not carry stories with no acceptance criteria into the sprint — flag them as blockers before committing +- [ ] Do not allow stories estimated at 8+ points into the sprint without splitting them first +- [ ] Do not ignore carry-over items when calculating capacity — they consume capacity and must be accounted for before new work is pulled in diff --git a/plugins/pm-delivery/skills/technical-spec-template/SKILL.md b/plugins/pm-delivery/skills/technical-spec-template/SKILL.md index 44c40ce..86f8134 100644 --- a/plugins/pm-delivery/skills/technical-spec-template/SKILL.md +++ b/plugins/pm-delivery/skills/technical-spec-template/SKILL.md @@ -147,3 +147,11 @@ Error codes: [list] - [ ] At least 2 alternative approaches are documented with reasons for rejection - [ ] Security and privacy section is completed for any feature touching user data - [ ] All open questions have a named owner and due date (not "TBD") + +## Anti-Patterns + +- [ ] Do not include solution language in the problem statement — the problem must be described independently of the proposed solution +- [ ] Do not omit alternatives considered — a spec that considers only one approach has not been properly evaluated +- [ ] Do not leave open questions as "TBD" without a named owner and due date — unresolved questions are blockers +- [ ] Do not skip security and privacy sections for any feature that touches user data +- [ ] Do not write a non-goals section that is empty — always list at least two things that might be assumed in scope diff --git a/plugins/pm-delivery/skills/user-story-writer/SKILL.md b/plugins/pm-delivery/skills/user-story-writer/SKILL.md index 27d66ce..62d3f26 100644 --- a/plugins/pm-delivery/skills/user-story-writer/SKILL.md +++ b/plugins/pm-delivery/skills/user-story-writer/SKILL.md @@ -209,6 +209,14 @@ Then the export contains only invoices from Jan 2026 — not all invoices - [ ] Out of scope is documented — not assumed - [ ] Stories are independent — they can be shipped individually without depending on unreleased work (except where explicitly noted) +## Anti-Patterns + +- [ ] Do not write user stories from a technical perspective — every story must be from the user's point of view and state their goal +- [ ] Do not write acceptance criteria that are untestable — every criterion must have a clear pass/fail condition +- [ ] Do not create stories that are too large to complete in a single sprint — break epics into estimable, independently deliverable stories +- [ ] Do not omit edge cases — unhappy paths and error states are required, not optional +- [ ] Do not skip the Definition of Done — without it, "done" means different things to different people + ## Example Trigger Phrases - "Write user stories for [feature] from this brief" diff --git a/plugins/pm-design/skills/accessibility-audit/SKILL.md b/plugins/pm-design/skills/accessibility-audit/SKILL.md index 61d88b0..3ac4ac2 100644 --- a/plugins/pm-design/skills/accessibility-audit/SKILL.md +++ b/plugins/pm-design/skills/accessibility-audit/SKILL.md @@ -167,6 +167,14 @@ Ask the user for these if not provided: - [ ] Effort estimates are included for prioritisation - [ ] Testing recommendations are included +## Anti-Patterns + +- [ ] Do not rely solely on automated scanning tools — automated checks catch ~30% of issues; manual keyboard and screen reader testing is required +- [ ] Do not label an issue "minor" simply because it only affects a small percentage of users — for those users it may block all access +- [ ] Do not add ARIA roles to fix broken semantics — use correct semantic HTML first; ARIA is a last resort +- [ ] Do not confuse colour contrast of text with colour contrast of UI components — they have different minimum ratios (4.5:1 vs 3:1) +- [ ] Do not audit only the happy path — error states, empty states, and loading states must also meet accessibility requirements + ## Example Trigger Phrases - "Audit this design for accessibility" diff --git a/plugins/pm-design/skills/design-critique/SKILL.md b/plugins/pm-design/skills/design-critique/SKILL.md index a6016f2..6228d96 100644 --- a/plugins/pm-design/skills/design-critique/SKILL.md +++ b/plugins/pm-design/skills/design-critique/SKILL.md @@ -1,6 +1,6 @@ --- name: design-critique -description: "Give structured, constructive feedback on any design. Use when asked to critique a design, review a UI, give feedback on a Figma file or wireframe, assess a user flow, or evaluate a design against UX principles. Applies Jobs-to-be-Done, Gestalt principles, and usability heuristics to give actionable feedback." +description: "Gives structured, constructive feedback on any design using UX frameworks. Use when asked to critique a design, review a UI, give feedback on a Figma file or wireframe, assess a user flow, or evaluate a design against UX principles. Applies Jobs-to-be-Done, Gestalt principles, and usability heuristics to give actionable feedback with prioritised issues and specific recommendations." --- # Design Critique Skill @@ -121,6 +121,14 @@ Prioritised list of the 3 most impactful changes. Each should be actionable in t - [ ] Priority levels (High/Medium/Low) reflect actual impact on user goal - [ ] Heuristic assessment only covers visible elements +## Anti-Patterns + +- [ ] Do not lead with visual preference (e.g. "I don't like the colour") — every issue must reference a UX principle or user impact +- [ ] Do not invent problems in the "What's Working" section — manufactured praise undermines the entire critique +- [ ] Do not provide the same priority level (High/Medium/Low) to every issue — prioritisation requires genuine judgment about user impact +- [ ] Do not skip the JTBD section for product screens — connecting feedback to the user's job-to-be-done is what separates UX critique from aesthetic opinion +- [ ] Do not give recommendations that require a full redesign when the user is in high-fidelity — scope recommendations to the design stage + ## Example Trigger Phrases - "Critique this design: [description or image]" diff --git a/plugins/pm-design/skills/design-system-audit/SKILL.md b/plugins/pm-design/skills/design-system-audit/SKILL.md index 1202509..701ee22 100644 --- a/plugins/pm-design/skills/design-system-audit/SKILL.md +++ b/plugins/pm-design/skills/design-system-audit/SKILL.md @@ -206,6 +206,14 @@ For each component, assess against these quality criteria: - [ ] Both Figma and code (Storybook/implementation) are assessed — not just Figma - [ ] Stakeholders from design, engineering, and product have reviewed the audit +## Anti-Patterns + +- [ ] Do not assess only the Figma library without checking the code implementation — Figma-code drift is one of the most common and costly design system failures +- [ ] Do not score adoption without interviewing teams — audit tool metrics miss the human reasons teams build custom components instead of using the system +- [ ] Do not treat all component gaps equally — prioritise gaps based on how many production screens rely on custom implementations, not alphabetically +- [ ] Do not recommend adding more components without first auditing documentation quality — an undocumented component is often worse than no component +- [ ] Do not schedule remediation without a named owner per initiative — design system improvements without ownership consistently stall + ## Example Trigger Phrases - "Audit our design system for consistency and coverage" diff --git a/plugins/pm-design/skills/ux-research-plan/SKILL.md b/plugins/pm-design/skills/ux-research-plan/SKILL.md index 3191d88..eb14fa8 100644 --- a/plugins/pm-design/skills/ux-research-plan/SKILL.md +++ b/plugins/pm-design/skills/ux-research-plan/SKILL.md @@ -152,6 +152,14 @@ For each insight: "This means we should [design/product implication]" or "This c - [ ] Synthesis framework is included - [ ] Incentive recommendation is included +## Anti-Patterns + +- [ ] Do not write a research plan without clearly stated research objectives — every methodology choice must flow from the objectives +- [ ] Do not design a plan that mixes generative and evaluative research without clearly separating them +- [ ] Do not omit screener criteria — recruiting unqualified participants invalidates the research +- [ ] Do not write discussion guide questions that are leading — questions must be neutral and open-ended +- [ ] Do not skip the incentive recommendation — uncompensated research has lower participant quality and completion rates + ## Example Trigger Phrases - "Write a research plan for [feature or product area]" diff --git a/plugins/pm-discovery/skills/assumption-mapper/SKILL.md b/plugins/pm-discovery/skills/assumption-mapper/SKILL.md index d9051cc..bc21daa 100644 --- a/plugins/pm-discovery/skills/assumption-mapper/SKILL.md +++ b/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) diff --git a/plugins/pm-discovery/skills/customer-journey-map/SKILL.md b/plugins/pm-discovery/skills/customer-journey-map/SKILL.md index 5106df3..7fda6b4 100644 --- a/plugins/pm-discovery/skills/customer-journey-map/SKILL.md +++ b/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]" diff --git a/plugins/pm-discovery/skills/discovery-interview-guide/SKILL.md b/plugins/pm-discovery/skills/discovery-interview-guide/SKILL.md index 5ded24a..73022fc 100644 --- a/plugins/pm-discovery/skills/discovery-interview-guide/SKILL.md +++ b/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 diff --git a/plugins/pm-discovery/skills/job-story-mapper/SKILL.md b/plugins/pm-discovery/skills/job-story-mapper/SKILL.md index 94f7270..6b6908e 100644 --- a/plugins/pm-discovery/skills/job-story-mapper/SKILL.md +++ b/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 diff --git a/plugins/pm-discovery/skills/user-interview-synthesis/SKILL.md b/plugins/pm-discovery/skills/user-interview-synthesis/SKILL.md index 0a0d6fb..ccb4c09 100644 --- a/plugins/pm-discovery/skills/user-interview-synthesis/SKILL.md +++ b/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 diff --git a/plugins/pm-engineering/skills/api-docs-writer/SKILL.md b/plugins/pm-engineering/skills/api-docs-writer/SKILL.md index 8cdb932..a69303f 100644 --- a/plugins/pm-engineering/skills/api-docs-writer/SKILL.md +++ b/plugins/pm-engineering/skills/api-docs-writer/SKILL.md @@ -141,6 +141,14 @@ data = response.json() - [ ] Enum values are listed where applicable - [ ] Pagination documented if the endpoint is a list endpoint +## Anti-Patterns + +- [ ] Do not document only the happy path — every endpoint must have error codes for at least 400, 401/403, 404, 429, and 500 +- [ ] Do not use placeholder values like "YOUR_ENDPOINT" or "INSERT_TOKEN" in code examples — use realistic-looking placeholders anchored to the actual base URL +- [ ] Do not skip enum values for fields with a fixed set of accepted values — undocumented enums cause integration bugs +- [ ] Do not omit pagination documentation on list endpoints — developers who miss this will build integrations that silently miss data +- [ ] Do not describe what a field "is" without describing what it "does" — "the ID" is not documentation; "the unique identifier used to retrieve or update this resource" is + ## Usage Examples - "Document this API endpoint: [paste spec or description]" - "Turn this Postman collection into developer docs" diff --git a/plugins/pm-engineering/skills/api-versioning-strategy/SKILL.md b/plugins/pm-engineering/skills/api-versioning-strategy/SKILL.md index 5db43a2..e1dc945 100644 --- a/plugins/pm-engineering/skills/api-versioning-strategy/SKILL.md +++ b/plugins/pm-engineering/skills/api-versioning-strategy/SKILL.md @@ -301,6 +301,14 @@ builders and response parsers. --- +## Anti-Patterns + +- [ ] Do not classify expanding an enum (new response values) as non-breaking — clients with exhaustive switch statements will break when they receive an unexpected enum value +- [ ] Do not set a sunset date without confirming it is achievable for the largest consumer — a sunset that forces consumers to miss a legal deadline will be ignored or escalated +- [ ] Do not maintain more than two simultaneous stable/deprecated versions — each additional supported version multiplies maintenance burden and consumer confusion +- [ ] Do not use "monitor traffic" as the sole mechanism for knowing when all consumers have migrated — track named consumers against migration completion explicitly +- [ ] Do not skip the migration guide — consumers will delay migration indefinitely without a step-by-step guide that estimates effort + ## Quality Checks - [ ] Versioning scheme recommendation includes explicit rationale tied to the API type and consumer type provided — not a generic recommendation diff --git a/plugins/pm-engineering/skills/architecture-decision-record/SKILL.md b/plugins/pm-engineering/skills/architecture-decision-record/SKILL.md index 25f4dbd..c2132b5 100644 --- a/plugins/pm-engineering/skills/architecture-decision-record/SKILL.md +++ b/plugins/pm-engineering/skills/architecture-decision-record/SKILL.md @@ -112,6 +112,14 @@ For each option, produce: - [ ] Context section states the problem explicitly in its first 1–2 sentences (does not assume the reader knows what problem the team was solving) - [ ] Each rejected option's "Why ruled out" explanation names a specific constraint or trade-off (not a circular statement like "didn't meet our requirements") +## Anti-Patterns + +- [ ] Do not write an ADR after the decision has already been fully implemented and the team has moved on — ADRs written retrospectively often omit the real reasons and alternatives +- [ ] Do not list only the chosen option — rejected options with honest reasons are the most valuable part of an ADR for future readers +- [ ] Do not write consequences that are all positive — every architectural decision involves trade-offs; an ADR with no negative consequences was not scrutinised honestly +- [ ] Do not leave the status as "Proposed" indefinitely — an ADR that no one has approved is not guiding anyone's decisions +- [ ] Do not write context that assumes the reader already knows what problem was being solved — the context section exists precisely for readers who lack that background + ## Usage Examples - "Write an ADR for using [technology]" - "Document our decision to [architectural choice]" diff --git a/plugins/pm-engineering/skills/capacity-planning/SKILL.md b/plugins/pm-engineering/skills/capacity-planning/SKILL.md index 548c9ea..da8d31a 100644 --- a/plugins/pm-engineering/skills/capacity-planning/SKILL.md +++ b/plugins/pm-engineering/skills/capacity-planning/SKILL.md @@ -346,6 +346,14 @@ Define the thresholds that require explicit action — not retrospective fixes a --- +## Anti-Patterns + +- [ ] Do not set capacity trigger thresholds without knowing the baseline — a "CPU > 70%" alert is meaningless if you don't know what normal looks like +- [ ] Do not plan only for average traffic — capacity plans that don't model peak load will result in incidents during the events that matter most +- [ ] Do not conflate vertical and horizontal scaling — adding more app servers without addressing database connection limits will not resolve the constraint +- [ ] Do not present growth projections as certainties — all forecasts have uncertainty; state the confidence level and provide a conservative and optimistic scenario +- [ ] Do not defer action items without a named owner and a specific date — a roadmap with no owners is a wish list + ## Quality Checks - [ ] Every resource has a quantified current utilisation and a projected months-to-ceiling — no hand-waving diff --git a/plugins/pm-engineering/skills/changelog-generator/SKILL.md b/plugins/pm-engineering/skills/changelog-generator/SKILL.md index e23762d..b0b2036 100644 --- a/plugins/pm-engineering/skills/changelog-generator/SKILL.md +++ b/plugins/pm-engineering/skills/changelog-generator/SKILL.md @@ -81,6 +81,14 @@ Follow [Keep a Changelog](https://keepachangelog.com) format: - [ ] No entries start with past-tense verbs (no "Added", "Fixed", "Removed" — use "Add", "Fix", "Remove") - [ ] Every breaking change entry includes a specific migration action (not just "update your code") +## Anti-Patterns + +- [ ] Do not include implementation details in changelog entries — users need to know what changed for them, not how the code was refactored internally +- [ ] Do not list every micro-commit as a separate entry — related commits should be grouped into one user-facing change +- [ ] Do not omit the migration path for breaking changes — a breaking change entry without a specific migration action forces users to read the source code +- [ ] Do not include empty sections — a "### Fixed" section with no entries signals the template was filled in carelessly +- [ ] Do not write breaking changes in the same casual tone as minor additions — breaking changes must be visually prominent and call out migration requirements explicitly + ## Usage Examples - "Write a changelog for version [X]" + [paste commits] - "Generate release notes from these commits" diff --git a/plugins/pm-engineering/skills/cicd-playbook/SKILL.md b/plugins/pm-engineering/skills/cicd-playbook/SKILL.md index 26f9cdc..32cd48e 100644 --- a/plugins/pm-engineering/skills/cicd-playbook/SKILL.md +++ b/plugins/pm-engineering/skills/cicd-playbook/SKILL.md @@ -292,6 +292,14 @@ Ask for these if not already provided: --- +## Anti-Patterns + +- [ ] Do not describe a rollback procedure that has never been tested — a theoretical rollback is not a rollback plan; test it in staging before production +- [ ] Do not allow deploys on Fridays or before holidays without an explicit on-call engineer who will monitor through the weekend +- [ ] Do not commit secrets to source control even in non-production branches — secret scanning in the pipeline catches this, but prevention is the standard +- [ ] Do not skip post-deploy monitoring after a production deploy — the deploying engineer must watch error rates and latency for the specified observation window +- [ ] Do not suppress a security scan finding without a linked ticket and a named owner — suppressions without accountability accumulate into unmanaged risk + ## Quality Checks - [ ] Every stage has a clear owner when it fails diff --git a/plugins/pm-engineering/skills/claude-superpowers/SKILL.md b/plugins/pm-engineering/skills/claude-superpowers/SKILL.md index 5def81a..45a3075 100644 --- a/plugins/pm-engineering/skills/claude-superpowers/SKILL.md +++ b/plugins/pm-engineering/skills/claude-superpowers/SKILL.md @@ -1,6 +1,6 @@ --- name: claude-superpowers -description: "Force Claude Code to work like a senior developer: plan before coding, work in isolation, write tests first, and review its own output twice before presenting it. Use when asked to enable superpowers mode, activate the superpowers framework, or turn on superpowers for this session. Installs a 4-stage framework — Plan, Isolate, Test First, Double Review — that prevents Claude from sprinting into broken code." +description: "Activate a 4-stage coding discipline framework that forces Claude to plan before coding, isolate changes on a branch, write tests first, and self-review output twice before presenting it. Use when starting a complex coding task, when past Claude sessions produced broken first drafts, or when you want to prevent rework cycles. Produces a confirmed written plan, isolated feature branch, test-first implementation, and a double-reviewed output with a correctness and code-quality checklist." --- # Claude Superpowers Skill @@ -269,6 +269,14 @@ Tell the user: "Add this to your CLAUDE.md and Superpowers will be active perman --- +## Anti-Patterns + +- [ ] Do not proceed to Stage 2 without explicit user confirmation of the plan — coding before confirmation defeats the entire purpose of the planning stage +- [ ] Do not write tests after the implementation and call it "test-first" — tests must be written and confirmed failing before the implementation starts +- [ ] Do not skip the Double Review when time is tight — the review is most valuable precisely when speed is the priority, because that is when errors are most likely +- [ ] Do not expand scope during Stage 2 without surfacing it — silent scope expansion produces code the user did not approve and may not want +- [ ] Do not mark both reviews as clean without actually performing them — a rubber-stamp review produces false confidence and defeats the framework + ## Example Trigger Phrases - "Enable superpowers mode" diff --git a/plugins/pm-engineering/skills/code-review-checklist/SKILL.md b/plugins/pm-engineering/skills/code-review-checklist/SKILL.md index 4683150..9d43e91 100644 --- a/plugins/pm-engineering/skills/code-review-checklist/SKILL.md +++ b/plugins/pm-engineering/skills/code-review-checklist/SKILL.md @@ -107,6 +107,14 @@ Based on the change type and language, flag 2-3 things reviewers typically miss - [ ] Decision framework includes at least one named blocking condition and one named non-blocking comment condition - [ ] Common pitfalls are specific to the stated language + change-type combo (not generic advice like "watch out for bugs") +## Anti-Patterns + +- [ ] Do not generate a generic checklist that ignores the stated language — a Python checklist and a Go checklist have fundamentally different correctness concerns +- [ ] Do not treat "looks fine" as a valid review outcome — the checklist exists to surface specific concerns, not validate a superficial read +- [ ] Do not scope a "high risk" review the same as a "low risk" review — depth must scale with the stated risk level +- [ ] Do not flag every stylistic preference as a blocking issue — distinguish between blocking correctness issues and non-blocking comments +- [ ] Do not skip the "common pitfalls" section for the stated language and change-type combination — this is where the most valuable knowledge lives + ## Usage Examples - "Generate a code review checklist for [PR description]" - "What should I check in this pull request?" diff --git a/plugins/pm-engineering/skills/context-mode/SKILL.md b/plugins/pm-engineering/skills/context-mode/SKILL.md index 02663e7..5b3dd8b 100644 --- a/plugins/pm-engineering/skills/context-mode/SKILL.md +++ b/plugins/pm-engineering/skills/context-mode/SKILL.md @@ -1,6 +1,6 @@ --- name: context-mode -description: "Activate output filtering, session logging, and auto-resume to keep Claude Code sessions running for hours without context bloat or memory loss. Use when asked to enable context mode, turn on long session mode, or activate session persistence. Installs a session log at project root, filters verbose command output before it enters context, and auto-resumes after Claude resets." +description: "Activate output filtering, session logging, and auto-resume to keep Claude Code sessions productive across resets. Use when starting a long or complex coding session, when previous sessions lost context mid-task, or when you need Claude to resume exactly where it left off after a reset. Installs a session.log at project root, filters verbose command output to preserve context, and automatically resumes in-progress tasks after any Claude reset." --- # Context Mode Skill diff --git a/plugins/pm-engineering/skills/database-migration-plan/SKILL.md b/plugins/pm-engineering/skills/database-migration-plan/SKILL.md index 582bba9..196d2e7 100644 --- a/plugins/pm-engineering/skills/database-migration-plan/SKILL.md +++ b/plugins/pm-engineering/skills/database-migration-plan/SKILL.md @@ -452,3 +452,11 @@ Follow this checklist on the day of migration. Mark each step as done before pro - [ ] Lock types are identified for every DDL statement — no "should be fine" assumptions - [ ] The deployment runbook names who runs each step, not just what to run - [ ] Phase 4 (contract) is explicitly gated on the rollback window passing — not run on the same day as Phase 3 + +## Anti-Patterns + +- [ ] Do not combine the expand and contract phases into a single deployment — they must be separated by a deployment cycle +- [ ] Do not run DDL changes without first testing on a production-sized data clone +- [ ] Do not skip the NOT VALID + VALIDATE pattern for constraint additions on large tables — it causes full table locks +- [ ] Do not define a rollback as "restore from backup" — each phase must have an explicit, fast rollback procedure +- [ ] Do not omit dual-write logic during the transition period — removing the old column before all writers are updated causes data loss diff --git a/plugins/pm-engineering/skills/database-schema-design/SKILL.md b/plugins/pm-engineering/skills/database-schema-design/SKILL.md index b10b10b..49df946 100644 --- a/plugins/pm-engineering/skills/database-schema-design/SKILL.md +++ b/plugins/pm-engineering/skills/database-schema-design/SKILL.md @@ -354,3 +354,11 @@ If this schema is being introduced to an existing system, note the migration app - [ ] JSONB columns are justified — not used as a substitute for proper schema design on queryable fields - [ ] Normalization decisions are documented with reasoning, not just stated - [ ] Migration notes address existing data if this is a schema change, not a greenfield schema + +## Anti-Patterns + +- [ ] Do not use JSONB columns as a substitute for proper relational schema design on fields that will be queried +- [ ] Do not add indexes speculatively — every index must be justified by a specific access pattern +- [ ] Do not omit timezone-awareness — use TIMESTAMPTZ, never plain TIMESTAMP +- [ ] Do not design without documenting normalization decisions — future maintainers need the reasoning, not just the structure +- [ ] Do not skip the access patterns section — schema without query patterns cannot be evaluated for correctness diff --git a/plugins/pm-engineering/skills/debugging-log-analyser/SKILL.md b/plugins/pm-engineering/skills/debugging-log-analyser/SKILL.md index a438416..5eb396f 100644 --- a/plugins/pm-engineering/skills/debugging-log-analyser/SKILL.md +++ b/plugins/pm-engineering/skills/debugging-log-analyser/SKILL.md @@ -1,6 +1,6 @@ --- name: debugging-log-analyser -description: "Parse error logs, stack traces, and crash reports into a structured root cause diagnosis. Use when sharing a log, stack trace, error output, or crash dump. Produces a structured diagnosis with probable root cause, affected code path, suggested fix, and next debugging steps." +description: "Parse error logs, stack traces, and crash reports into a structured root cause diagnosis. Use when an application is throwing exceptions, crashing, or producing unexpected errors and you need to understand why and what to fix. Produces a structured diagnosis with error classification, stack trace walkthrough, probable root cause with confidence level, affected code path, a concrete code-level fix suggestion, and ordered next debugging steps." --- # Debugging Log Analyser Skill diff --git a/plugins/pm-engineering/skills/dependency-audit/SKILL.md b/plugins/pm-engineering/skills/dependency-audit/SKILL.md index e50f627..d0daad6 100644 --- a/plugins/pm-engineering/skills/dependency-audit/SKILL.md +++ b/plugins/pm-engineering/skills/dependency-audit/SKILL.md @@ -1,6 +1,6 @@ --- name: dependency-audit -description: "Conduct a dependency audit for a project — checking for security vulnerabilities, license compliance issues, outdated packages, and transitive dependency risk. Use when asked to audit dependencies, review package security, check license compliance, assess dependency health, or produce a vulnerability report. Produces a vulnerability findings table, license compliance matrix, update priority matrix, dependency health score, and 30-day remediation plan." +description: "Audits project dependencies for security vulnerabilities, license compliance issues, outdated packages, and transitive dependency risk. Use when asked to audit dependencies, review package security, check license compliance, assess dependency health, or produce a vulnerability report. Produces a vulnerability findings table, license compliance matrix, update priority matrix, dependency health score, and 30-day remediation plan." --- # Dependency Audit Skill @@ -330,3 +330,11 @@ go-licenses check ./... --allowed_licenses=MIT,Apache-2.0,BSD-2-Clause,BSD-3-Cla - [ ] CI pipeline change is included — the audit findings should be the last time these are caught manually - [ ] The dependency health score is calculated from actual findings, not estimated - [ ] Remediation plan actions are specific commands or steps, not "upgrade package X" without version targets + +## Anti-Patterns + +- [ ] Do not report only direct dependencies — transitive dependency vulnerabilities are often more dangerous and are the most commonly missed +- [ ] Do not present raw audit tool output without interpretation — a table of 200 CVEs with no prioritisation is worse than no audit at all +- [ ] Do not assign all Critical CVEs as "fix immediately" without checking whether an exploitable path exists in your usage context +- [ ] Do not make license compliance decisions without legal input — flagging a GPL dependency without a recommendation is incomplete work +- [ ] Do not complete the audit without including a CI/CD pipeline step — a one-time audit that leaves the door open for new vulnerabilities is not a remediation diff --git a/plugins/pm-engineering/skills/developer-onboarding-doc/SKILL.md b/plugins/pm-engineering/skills/developer-onboarding-doc/SKILL.md index 91e3b93..341a868 100644 --- a/plugins/pm-engineering/skills/developer-onboarding-doc/SKILL.md +++ b/plugins/pm-engineering/skills/developer-onboarding-doc/SKILL.md @@ -330,3 +330,11 @@ curl http://localhost:[PORT]/health - [ ] On-call section has real links, not placeholders - [ ] Contacts are current — team members with real Slack handles - [ ] Troubleshooting covers the top 3 actual questions new joiners ask + +## Anti-Patterns + +- [ ] Do not document the ideal setup — document the actual setup; real oddities and gotchas are what new engineers need most +- [ ] Do not leave placeholder contacts like "ask your manager" — name specific people for each domain or the doc becomes useless when the new joiner has an urgent question +- [ ] Do not write the onboarding doc without reviewing it with a recent joiner — the author is blind to what they take for granted +- [ ] Do not include every piece of architectural detail — an onboarding doc that covers everything teaches nothing; link to deeper docs instead +- [ ] Do not skip the "things that might surprise you" section — undocumented non-obvious patterns are the number one cause of wasted engineering time in the first week diff --git a/plugins/pm-engineering/skills/disaster-recovery-plan/SKILL.md b/plugins/pm-engineering/skills/disaster-recovery-plan/SKILL.md index 2e14b16..24e8084 100644 --- a/plugins/pm-engineering/skills/disaster-recovery-plan/SKILL.md +++ b/plugins/pm-engineering/skills/disaster-recovery-plan/SKILL.md @@ -558,3 +558,11 @@ Run this checklist quarterly and before any major infrastructure change: - [ ] Contact list contains current phone numbers, not just Slack handles (Slack may be down during a DR event) - [ ] Security breach runbook (3.5) explicitly names the security team contact and does not attempt self-remediation - [ ] All thresholds (RTO/RPO) are visible in the monitoring dashboard so actual vs. target is measurable in real time + +## Anti-Patterns + +- [ ] Do not write runbook commands without testing them — an untested command in a runbook is actively dangerous during a real disaster when cognitive load is highest +- [ ] Do not set RTO/RPO targets without business sign-off — technical teams often set aspirational targets that do not reflect actual business cost tolerance for downtime +- [ ] Do not include only the "happy path" of each failover scenario — runbooks must explicitly cover what to do when the recovery step itself fails +- [ ] Do not list Slack handles as the only escalation contact — Slack may be unavailable during a region-wide failure; phone numbers are mandatory +- [ ] Do not schedule DR game days without pre-committing to fix the gaps found — a game day that produces action items no one owns is theater, not preparedness diff --git a/plugins/pm-engineering/skills/engineering-hiring-rubric/SKILL.md b/plugins/pm-engineering/skills/engineering-hiring-rubric/SKILL.md index 2d3b5a0..82c6494 100644 --- a/plugins/pm-engineering/skills/engineering-hiring-rubric/SKILL.md +++ b/plugins/pm-engineering/skills/engineering-hiring-rubric/SKILL.md @@ -336,3 +336,11 @@ Brief every interviewer on these before they conduct their first interview for t - [ ] Scorecard uses observable behavior fields ("What did the candidate do or say") — not impression fields - [ ] Must-hire competencies are explicitly named for the role and level - [ ] Debrief agenda enforces written scorecard submission before verbal discussion to prevent anchoring + +## Anti-Patterns + +- [ ] Do not use a single behavioral anchor description per competency — you must define what Strong Hire AND No Hire look like separately, or interviewers cannot calibrate +- [ ] Do not allow "culture fit" as a standalone assessment dimension — it masks similarity bias; all judgments must use observable behavioral evidence +- [ ] Do not let interviewers share scorecard feedback before the debrief — verbal pre-debrief discussion anchors everyone to the first opinion expressed +- [ ] Do not set the same must-hire competency list for all engineering roles — a senior backend engineer and a frontend engineer have different non-negotiable competencies +- [ ] Do not skip the calibration bias notes section — interviewers who have never been briefed on halo effect, recency bias, and credential bias will reproduce them in every loop diff --git a/plugins/pm-engineering/skills/engineering-weekly-report/SKILL.md b/plugins/pm-engineering/skills/engineering-weekly-report/SKILL.md index b33141a..18987ba 100644 --- a/plugins/pm-engineering/skills/engineering-weekly-report/SKILL.md +++ b/plugins/pm-engineering/skills/engineering-weekly-report/SKILL.md @@ -162,3 +162,11 @@ If no decisions are pending: *No decisions pending.* - [ ] Escalations that need leadership attention are called out explicitly in the Risks section — not just buried in a table row - [ ] The entire report is readable in under 2 minutes — if it is longer than one printed page, trim it - [ ] Report period (week number and date range) is clearly stated in the header + +## Anti-Patterns + +- [ ] Do not fabricate metrics — if data is not available, mark the field as `[data needed]` rather than estimating; stakeholders making decisions on invented numbers is actively harmful +- [ ] Do not write next week's priorities as activities ("work on X") — they must be outcomes ("ship X", "complete Y migration") so stakeholders can evaluate whether the team delivered +- [ ] Do not bury escalations inside a risk table row — anything needing leadership attention must be called out explicitly in the Escalations section +- [ ] Do not list blocked items without naming a specific owner and a concrete unblocking action — "waiting on X" is not a blocker entry, it is a placeholder +- [ ] Do not write a report that exceeds two printed pages — length signals the author has not done the editorial work of deciding what matters to stakeholders diff --git a/plugins/pm-engineering/skills/feature-flag-guide/SKILL.md b/plugins/pm-engineering/skills/feature-flag-guide/SKILL.md index 323e5b1..8ea51ba 100644 --- a/plugins/pm-engineering/skills/feature-flag-guide/SKILL.md +++ b/plugins/pm-engineering/skills/feature-flag-guide/SKILL.md @@ -367,3 +367,11 @@ All flag changes in production must be traceable. Ensure the following are confi - [ ] Stale flag detection runs automatically and results are reviewed weekly - [ ] Code review checklist includes: "Does this PR introduce a flag? If yes, is the creation checklist complete?" - [ ] At least one person other than the flag owner knows how to disable any given flag in an emergency + +## Anti-Patterns + +- [ ] Do not create release flags without a cleanup date — flags without expiry dates become permanent technical debt that accumulates silently until the codebase is unmaintainable +- [ ] Do not skip monitoring setup for flags between 1–99% rollout — a partially-rolled-out flag without metric comparison is a risk without a sensor +- [ ] Do not nest flags inside other flags — compound flag logic makes cleanup nearly impossible and creates untestable code paths +- [ ] Do not allow flag owners to leave the team without reassigning ownership — orphan flags with no owner never get cleaned up +- [ ] Do not use feature flags as a permanent configuration system — flags that have been at 100% or 0% for more than 30 days must be cleaned up; using flags as permanent config couples business logic to a feature flag platform diff --git a/plugins/pm-engineering/skills/incident-postmortem/SKILL.md b/plugins/pm-engineering/skills/incident-postmortem/SKILL.md index 1b060a6..7390bec 100644 --- a/plugins/pm-engineering/skills/incident-postmortem/SKILL.md +++ b/plugins/pm-engineering/skills/incident-postmortem/SKILL.md @@ -140,6 +140,14 @@ Rules for action items: - [ ] No action item contains vague language like "improve monitoring", "increase resilience", or "better testing" — each must name a specific change - [ ] Executive summary is readable by non-technical leadership +## Anti-Patterns + +- [ ] Do not assign blame to individuals — postmortems must focus on system and process failures +- [ ] Do not write action items with vague language like "improve monitoring" — each must name a specific, ownable change +- [ ] Do not skip the contributing factors — root cause alone misses the systemic issues that enable incidents +- [ ] Do not omit the detection timeline — how long it took to detect matters as much as how long it took to resolve +- [ ] Do not treat the postmortem as closed until all action items have named owners and due dates + ## Usage Examples - "Write a postmortem for the [incident name] outage" - "Help me write a P1 incident report" diff --git a/plugins/pm-engineering/skills/infra-as-code-review/SKILL.md b/plugins/pm-engineering/skills/infra-as-code-review/SKILL.md index 65c88f8..5b5f3e3 100644 --- a/plugins/pm-engineering/skills/infra-as-code-review/SKILL.md +++ b/plugins/pm-engineering/skills/infra-as-code-review/SKILL.md @@ -290,3 +290,11 @@ Medium and Low findings should be tracked as follow-up issues with a committed r - [ ] Code snippets in findings show both the problematic code AND the corrected version - [ ] Overall risk rating is justified by the highest-severity open finding - [ ] Checklist items are binary (checkable) — not narrative observations + +## Anti-Patterns + +- [ ] Do not mark a finding as Low if it involves hardcoded credentials or secrets in any form — always Critical +- [ ] Do not review IaC in isolation from the deployment context — networking and IAM must be evaluated together +- [ ] Do not produce narrative findings without the specific resource name, file, and line number +- [ ] Do not skip the "Required Actions Before Merge" summary — reviewers need a clear blocking list, not just a full report +- [ ] Do not approve code where encryption at rest or in transit is missing on data stores, even if not explicitly flagged by the requester diff --git a/plugins/pm-engineering/skills/load-testing-plan/SKILL.md b/plugins/pm-engineering/skills/load-testing-plan/SKILL.md index fe39119..9719b99 100644 --- a/plugins/pm-engineering/skills/load-testing-plan/SKILL.md +++ b/plugins/pm-engineering/skills/load-testing-plan/SKILL.md @@ -430,3 +430,11 @@ load-test: - [ ] CI integration blocks promotion on threshold failure — not just records results - [ ] Soak test has been run at least once to establish a memory and connection pool baseline - [ ] Results comparison to previous run is part of the analysis — not just absolute pass/fail + +## Anti-Patterns + +- [ ] Do not set thresholds without grounding them in actual SLO targets or production baselines — arbitrary numbers produce meaningless pass/fail results +- [ ] Do not run the load generator on the same host as the service under test — this contaminates both the test results and the service metrics +- [ ] Do not use production user data in load test seeding — all test data must be synthetic, tagged, and cleaned up after each run +- [ ] Do not skip the soak test on first deployment — only a soak test reveals slow memory leaks and connection pool exhaustion that short tests miss +- [ ] Do not treat a passing baseline test as evidence the service handles spikes — baseline, stress, spike, and soak scenarios test fundamentally different failure modes diff --git a/plugins/pm-engineering/skills/local-dev-setup/SKILL.md b/plugins/pm-engineering/skills/local-dev-setup/SKILL.md index 70512f3..d11bccd 100644 --- a/plugins/pm-engineering/skills/local-dev-setup/SKILL.md +++ b/plugins/pm-engineering/skills/local-dev-setup/SKILL.md @@ -482,3 +482,11 @@ Before opening your first pull request, verify: - [ ] Docker Compose version and Docker Desktop memory requirements are stated explicitly - [ ] "Expected output" is shown for key commands so engineers know whether a step succeeded - [ ] Setup time estimate is honest — verified by timing a real onboarding session, not estimated + +## Anti-Patterns + +- [ ] Do not write setup steps from memory without testing them on a clean machine — steps that skip implicit knowledge break for new engineers +- [ ] Do not leave environment variables undocumented — every variable in .env.example must appear in the Variables table with a description and source +- [ ] Do not write troubleshooting entries for theoretical issues — only include problems that have actually occurred during real onboarding sessions +- [ ] Do not assume Docker Desktop is configured correctly — memory limits and platform (M1/M2) compatibility must be explicitly called out +- [ ] Do not omit expected output for key commands — without "expected output", engineers cannot tell whether a step succeeded or silently failed diff --git a/plugins/pm-engineering/skills/microservices-decomposition/SKILL.md b/plugins/pm-engineering/skills/microservices-decomposition/SKILL.md index d4c109a..4980f8e 100644 --- a/plugins/pm-engineering/skills/microservices-decomposition/SKILL.md +++ b/plugins/pm-engineering/skills/microservices-decomposition/SKILL.md @@ -288,3 +288,11 @@ Conway's Law: the architecture of a system mirrors the communication structure o - [ ] If decomposing a monolith, the strangler fig migration plan has phases with durations, dependencies, and success criteria - [ ] Risk register addresses at minimum: data consistency, distributed transactions, and Conway's Law alignment - [ ] Organizational alignment section maps services to teams and identifies misalignments that need to be resolved + +## Anti-Patterns + +- [ ] Do not define service boundaries before completing the domain analysis — services derived without bounded context mapping will split the wrong things and couple the wrong things +- [ ] Do not assign multiple teams as co-owners of a single service — shared ownership is no ownership; every service needs exactly one team accountable for it +- [ ] Do not default to synchronous REST calls for all inter-service communication — using sync calls where async events would decouple services creates cascading failure modes +- [ ] Do not propose more than one service per bounded context without a clear justification — over-decomposition (nanoservices) creates operational overhead that exceeds the decomposition benefit +- [ ] Do not begin migration without deploying distributed tracing first — migrating without observability means flying blind when the first extraction causes a production incident diff --git a/plugins/pm-engineering/skills/monitoring-setup-guide/SKILL.md b/plugins/pm-engineering/skills/monitoring-setup-guide/SKILL.md index a59d03b..917796f 100644 --- a/plugins/pm-engineering/skills/monitoring-setup-guide/SKILL.md +++ b/plugins/pm-engineering/skills/monitoring-setup-guide/SKILL.md @@ -434,3 +434,11 @@ Honest assessment of what is missing today and what the priority to add it is: - [ ] The primary dashboard answers "is the service healthy?" in under 10 seconds — no hunting for the right panel - [ ] Business metrics are tracked alongside infrastructure metrics — not just four golden signals - [ ] Observability debt items have owners and dates — not just "would be nice to have" + +## Anti-Patterns + +- [ ] Do not create alerts without a specific on-call action — an alert that just says "investigate" trains engineers to ignore it +- [ ] Do not set alert thresholds from a template without calibrating against production baselines — uncalibrated thresholds cause either alert fatigue or missed incidents +- [ ] Do not log PII, tokens, or secrets — a logging standard is incomplete without an explicit list of what must never be logged +- [ ] Do not measure only the four golden signals without adding at least one business metric alert — infrastructure health can be green while the business-critical path is silently failing +- [ ] Do not deploy distributed tracing without verifying that trace IDs propagate across all service boundaries — partial tracing is worse than no tracing because it produces misleading incomplete traces diff --git a/plugins/pm-engineering/skills/oncall-runbook/SKILL.md b/plugins/pm-engineering/skills/oncall-runbook/SKILL.md index 957996e..0adf099 100644 --- a/plugins/pm-engineering/skills/oncall-runbook/SKILL.md +++ b/plugins/pm-engineering/skills/oncall-runbook/SKILL.md @@ -362,3 +362,11 @@ ANYTHING ELSE: - [ ] Diagnostic commands work — they have been run by at least one person recently - [ ] Handoff template is used at every shift change — not just during incidents - [ ] "Things I had to figure out that weren't documented" are added to this runbook after every incident + +## Anti-Patterns + +- [ ] Do not write alert runbooks with vague diagnostic steps like "check the logs" — every step must specify the exact command, dashboard link, or query to run +- [ ] Do not include an alert in the runbook that has no specific on-call action — an alert that pages someone with no defined response path creates panic, not resolution +- [ ] Do not leave the rollback command undocumented or untested — a rollback procedure that has never been run will fail when needed most +- [ ] Do not list escalation contacts without phone numbers and Slack handles — email-only escalation paths are useless during a 3am incident +- [ ] Do not write the runbook once and treat it as permanent — runbooks go stale after incidents; every incident must trigger a review of the relevant runbook entries diff --git a/plugins/pm-engineering/skills/performance-budget/SKILL.md b/plugins/pm-engineering/skills/performance-budget/SKILL.md index 4848859..374815d 100644 --- a/plugins/pm-engineering/skills/performance-budget/SKILL.md +++ b/plugins/pm-engineering/skills/performance-budget/SKILL.md @@ -275,3 +275,11 @@ When a breach is detected, work through this checklist in order: - [ ] Budget breach response process names specific Slack channels and owners - [ ] Budget thresholds are anchored to baseline measurements or a justified target — not pulled from thin air - [ ] Per-journey targets are defined for critical user journeys, not just global averages + +## Anti-Patterns + +- [ ] Do not set budget thresholds without measuring a current baseline first — targets must be anchored to reality +- [ ] Do not define global averages only — critical user journeys need individual budgets as they may diverge significantly +- [ ] Do not omit CI enforcement — a performance budget that is not enforced in the build pipeline will not be respected +- [ ] Do not leave the breach response process without named owners and escalation channels +- [ ] Do not set budgets that apply only to one environment — production and staging targets should be documented separately if they differ diff --git a/plugins/pm-engineering/skills/pr-description-writer/SKILL.md b/plugins/pm-engineering/skills/pr-description-writer/SKILL.md index 19ee525..8cf622c 100644 --- a/plugins/pm-engineering/skills/pr-description-writer/SKILL.md +++ b/plugins/pm-engineering/skills/pr-description-writer/SKILL.md @@ -82,6 +82,14 @@ Flag anything that warrants extra attention: - [ ] Testing steps are reproducible by someone unfamiliar with the code - [ ] For high-risk PRs, Reviewer Notes flags at least one specific area of concern or deliberate trade-off; for low-risk PRs, Reviewer Notes is either omitted or kept to one line +## Anti-Patterns + +- [ ] Do not write a description that only restates what changed — explain why the change was made +- [ ] Do not skip the testing steps — reviewers need to know how to verify the change works +- [ ] Do not omit the reviewer notes for high-risk PRs — flag deliberate trade-offs and areas needing careful review +- [ ] Do not describe implementation details that are obvious from the diff — add context that the diff cannot convey +- [ ] Do not produce a single paragraph — structure with headers so reviewers can navigate to what they need + ## Usage Examples - "Write a PR description for these changes" + [paste diff or description] - "Draft a pull request for [feature]" diff --git a/plugins/pm-engineering/skills/rfc-writer/SKILL.md b/plugins/pm-engineering/skills/rfc-writer/SKILL.md index a43c3b3..cf6c117 100644 --- a/plugins/pm-engineering/skills/rfc-writer/SKILL.md +++ b/plugins/pm-engineering/skills/rfc-writer/SKILL.md @@ -397,3 +397,11 @@ Accept the current state and revisit the problem in [timeframe]. - [ ] Open questions are assigned to named owners with deadlines — not floating - [ ] The RFC is written to be read by someone who was not in the planning conversations - [ ] Migration plan addresses all affected parties — users, API consumers, data — not just the technical steps + +## Anti-Patterns + +- [ ] Do not write the RFC as a persuasion document — its purpose is to expose trade-offs, not sell a decision +- [ ] Do not list alternatives without explicit rejection reasons — "we preferred the proposed solution" is not a reason +- [ ] Do not leave the security implications section blank or write "N/A" without a reasoned explanation +- [ ] Do not write open questions without assigning a named owner and a resolution deadline +- [ ] Do not skip the "impact of not solving this" section — without it, reviewers cannot assess urgency diff --git a/plugins/pm-engineering/skills/runbook-writer/SKILL.md b/plugins/pm-engineering/skills/runbook-writer/SKILL.md index fdb77bc..ce10618 100644 --- a/plugins/pm-engineering/skills/runbook-writer/SKILL.md +++ b/plugins/pm-engineering/skills/runbook-writer/SKILL.md @@ -145,3 +145,11 @@ After completing the runbook: - "I need a runbook for [procedure]" - "Document the operational procedure for [X]" - "Write an ops playbook for [scenario]" + +## Anti-Patterns + +- [ ] Do not write steps as vague actions like "run the deploy script" — every step must include the exact command +- [ ] Do not leave the rollback section as a placeholder — a runbook without a tested rollback procedure is incomplete and dangerous +- [ ] Do not omit expected output for each step — without it, the on-call engineer cannot tell if the step succeeded +- [ ] Do not write escalation contacts as "[Team name]" — every escalation row must have a real contact or an explicit flag to fill in +- [ ] Do not assume the reader knows the system — write for someone who has never touched it before diff --git a/plugins/pm-engineering/skills/security-threat-model/SKILL.md b/plugins/pm-engineering/skills/security-threat-model/SKILL.md index 1b18075..11ae487 100644 --- a/plugins/pm-engineering/skills/security-threat-model/SKILL.md +++ b/plugins/pm-engineering/skills/security-threat-model/SKILL.md @@ -251,3 +251,11 @@ Accepted risks are threats the team has decided not to mitigate right now. Every - [ ] STRIDE analysis covers all major components — not just the API layer - [ ] Mitigation actions are specific enough to become a ticket (not "improve security") - [ ] The ASCII trust boundary diagram matches the architecture description provided + +## Anti-Patterns + +- [ ] Do not restrict STRIDE analysis to only the API layer — threats exist at every component including the database and internal services +- [ ] Do not leave mitigations as vague directives like "improve security" — every mitigation must be specific enough to become a ticket +- [ ] Do not accept risks without a named owner and a review date — unowned accepted risks are not managed risks +- [ ] Do not write a threat model that covers only theoretical threats — prioritise by likelihood and impact using the risk register +- [ ] Do not omit the asset register — without knowing what is being protected, the STRIDE analysis has no anchor diff --git a/plugins/pm-engineering/skills/service-catalog-entry/SKILL.md b/plugins/pm-engineering/skills/service-catalog-entry/SKILL.md index 9292e92..56739bc 100644 --- a/plugins/pm-engineering/skills/service-catalog-entry/SKILL.md +++ b/plugins/pm-engineering/skills/service-catalog-entry/SKILL.md @@ -290,3 +290,11 @@ Document limitations honestly — this section prevents other teams from buildin - [ ] All runbook links are live — not broken references or TODO placeholders - [ ] Data classification includes retention period and encryption status — not just sensitivity level - [ ] The entry has been reviewed by at least one consumer team to confirm it matches their experience of the service + +## Anti-Patterns + +- [ ] Do not write aspirational SLO targets — targets must be agreed with stakeholders and based on historical data, not copied from a template +- [ ] Do not leave runbook links as TODO placeholders — broken or missing links make the catalog entry worse than useless during an incident +- [ ] Do not omit the "Known Limitations" section to make the service look better — undisclosed limitations cause incorrect integrations and downstream incidents +- [ ] Do not list API error codes without testing them — aspirational error documentation misleads consumers +- [ ] Do not write the "What It Does" section with jargon — a new engineer from another team must understand it in under 2 minutes diff --git a/plugins/pm-engineering/skills/slo-error-budget/SKILL.md b/plugins/pm-engineering/skills/slo-error-budget/SKILL.md index 05375e9..40995da 100644 --- a/plugins/pm-engineering/skills/slo-error-budget/SKILL.md +++ b/plugins/pm-engineering/skills/slo-error-budget/SKILL.md @@ -229,3 +229,11 @@ This policy defines what to do with the error budget — both when it's healthy - [ ] Error budget policy has clear triggers and clear actions — not "discuss as a team" - [ ] Burn rate alerts have different windows to catch both fast burns and slow burns - [ ] Exclusions are documented so they don't silently inflate the SLO number + +## Anti-Patterns + +- [ ] Do not set SLO targets at 100% — this discourages feature development and does not reflect how users experience reliability +- [ ] Do not measure internal system metrics as SLIs — SLIs must reflect what users directly experience, not internal CPU or memory +- [ ] Do not write an error budget policy with vague triggers — "discuss as a team" is not an actionable policy; triggers must be specific percentages +- [ ] Do not base targets on aspirational round numbers — always derive from historical baseline data +- [ ] Do not configure only one burn-rate alert window — a single window misses both fast burns and slow burns that exhaust the budget quietly diff --git a/plugins/pm-engineering/skills/sprint-velocity-analysis/SKILL.md b/plugins/pm-engineering/skills/sprint-velocity-analysis/SKILL.md index 99c094d..20c35eb 100644 --- a/plugins/pm-engineering/skills/sprint-velocity-analysis/SKILL.md +++ b/plugins/pm-engineering/skills/sprint-velocity-analysis/SKILL.md @@ -261,3 +261,11 @@ If cycle time data was not provided: *Cycle time data was not included in this a - [ ] Next-sprint capacity forecast uses historical average as the baseline and deducts specific known reducers - [ ] Health diagnosis table uses Red/Yellow/Green with evidence cited in the Evidence column — no unsupported scores - [ ] If metrics are missing (cycle time, blocker log), the report explicitly calls them out as recommended additions + +## Anti-Patterns + +- [ ] Do not generate the velocity chart from placeholder data — it must reflect the actual sprint data provided +- [ ] Do not diagnose trend direction without computing trailing vs leading averages — "it looks like it's declining" is not a diagnosis +- [ ] Do not list carry-over as a generic observation — identify root cause categories with counts for the analysis to be actionable +- [ ] Do not produce recommendations without a named owner, a start date, and a measurable target +- [ ] Do not score health dimensions without citing evidence in the Evidence column — unsupported Red/Yellow/Green scores are not credible diff --git a/plugins/pm-engineering/skills/system-design-interview/SKILL.md b/plugins/pm-engineering/skills/system-design-interview/SKILL.md index 5c83362..3e81e14 100644 --- a/plugins/pm-engineering/skills/system-design-interview/SKILL.md +++ b/plugins/pm-engineering/skills/system-design-interview/SKILL.md @@ -125,6 +125,14 @@ Things to tackle in production but out of scope for this design session: - [ ] Trade-offs section is honest (not just benefits of chosen approach) - [ ] Data flow is described end-to-end for the critical path +## Anti-Patterns + +- [ ] Do not jump to solutions before clarifying requirements — always establish functional and non-functional requirements first +- [ ] Do not present a design without discussing trade-offs — every architecture decision has costs and benefits that must be acknowledged +- [ ] Do not use vague capacity estimates — show the actual calculation (QPS, storage bytes, bandwidth) not just "this handles scale" +- [ ] Do not design for unlimited scale by default — match the design to the requirements stated +- [ ] Do not skip the data model — a system design without entity definitions and data flow is incomplete + ## Usage Examples - "Help me answer a system design interview: [question]" - "Design [system] for a system design interview" diff --git a/plugins/pm-engineering/skills/tech-radar/SKILL.md b/plugins/pm-engineering/skills/tech-radar/SKILL.md index 0206e59..97fe3b9 100644 --- a/plugins/pm-engineering/skills/tech-radar/SKILL.md +++ b/plugins/pm-engineering/skills/tech-radar/SKILL.md @@ -288,3 +288,11 @@ This log records every ring movement since the radar's first edition. Use it to - [ ] Maintenance process includes: nomination channel, review cadence, who decides, and ring-change criteria - [ ] Technologies identified as "strategic bets" in the inputs are placed in Adopt (if proven) or Trial (if being rolled out) - [ ] Technologies identified for deprecation are in Hold with a rationale that references the replacement + +## Anti-Patterns + +- [ ] Do not place a technology in Adopt without evidence it is proven at the team's scale — aspirational placements mislead engineers +- [ ] Do not add a blip without a written rationale paragraph — table rows without context are unusable +- [ ] Do not create a Hold entry without specifying a concrete migration path or target technology +- [ ] Do not skip the maintenance process — a radar with no process for updates becomes stale within two quarters +- [ ] Do not omit ring definitions — engineers need to know what they should do in response to each ring, not just what the ring means diff --git a/plugins/pm-engineering/skills/technical-debt-register/SKILL.md b/plugins/pm-engineering/skills/technical-debt-register/SKILL.md index 92c463c..9f373aa 100644 --- a/plugins/pm-engineering/skills/technical-debt-register/SKILL.md +++ b/plugins/pm-engineering/skills/technical-debt-register/SKILL.md @@ -258,3 +258,11 @@ Items where the cost of remediation currently exceeds the business value, accept - [ ] Accepted/deferred items have a review date and a named owner — no permanently deferred items - [ ] The register distinguishes between debt (deliberate or accumulated shortcuts) and bugs (unintended defects) - [ ] Items are closed as resolved only when acceptance criteria are met — not when the PR is merged + +## Anti-Patterns + +- [ ] Do not score debt items arbitrarily — priority scores must be calculated using the documented formula +- [ ] Do not conflate technical debt (deliberate shortcuts) with bugs (unintended defects) — they require different remediation strategies +- [ ] Do not underrate security and dependency items because they feel abstract — score based on actual business impact +- [ ] Do not create "permanently deferred" items — every accepted item must have a review date and named owner +- [ ] Do not include resolution plans that are vague descriptions — each plan must have specific, ticketable steps diff --git a/plugins/pm-engineering/skills/test-strategy-doc/SKILL.md b/plugins/pm-engineering/skills/test-strategy-doc/SKILL.md index a39d188..8fbd110 100644 --- a/plugins/pm-engineering/skills/test-strategy-doc/SKILL.md +++ b/plugins/pm-engineering/skills/test-strategy-doc/SKILL.md @@ -122,6 +122,14 @@ Testing is complete when: - [ ] Each test type names a concrete tool (not "some testing framework") - [ ] Definition of Done is measurable (not "tests are done when QA is happy") +## Anti-Patterns + +- [ ] Do not write a test strategy without a risk table that drives test priority — generic coverage targets are not a strategy +- [ ] Do not leave the "out of scope" section blank — every test strategy must explicitly name what is not being tested and why +- [ ] Do not specify test types without naming a concrete tool for each — "some testing framework" is not actionable +- [ ] Do not define a Definition of Done that is not measurable — "QA is happy" is not a completion criterion +- [ ] Do not create P0 risk areas without corresponding P0 test cases — risk rating must map to test coverage + ## Usage Examples - "Write a test strategy for [feature]" + [paste spec or PRD] - "Create a test plan for [system]" diff --git a/plugins/pm-essentials/skills/competitive-analysis/SKILL.md b/plugins/pm-essentials/skills/competitive-analysis/SKILL.md index 14a6202..500c06d 100644 --- a/plugins/pm-essentials/skills/competitive-analysis/SKILL.md +++ b/plugins/pm-essentials/skills/competitive-analysis/SKILL.md @@ -84,6 +84,13 @@ Position competitors on two key dimensions relevant to the market: **Medium-term (3-12 months):** 1. [Action] — [Rationale] +## Anti-Patterns + +- [ ] Do not present competitor feature claims as facts without citing a source or flagging them as assumptions — outdated or incorrect feature data misleads sales and product decisions +- [ ] Do not build a competitive analysis that only covers features — pricing, messaging, go-to-market motion, and who they hire for are equally strategic signals +- [ ] Do not treat all buyers as identical — the same product may win against Competitor A in the enterprise segment and lose in SMB; segment-specific win/loss matters +- [ ] Do not soften weaknesses and threats in the SWOT to avoid internal discomfort — an honest SWOT is only useful if the negatives are real + ## Quality Checks - [ ] All competitor claims cite a source or are flagged as assumptions diff --git a/plugins/pm-essentials/skills/docx-tracked-changes/SKILL.md b/plugins/pm-essentials/skills/docx-tracked-changes/SKILL.md index 55b1b71..e89dfa8 100644 --- a/plugins/pm-essentials/skills/docx-tracked-changes/SKILL.md +++ b/plugins/pm-essentials/skills/docx-tracked-changes/SKILL.md @@ -110,6 +110,14 @@ Instructions for applying the redline: - [ ] Pattern issues identified separately from individual changes - [ ] Application instructions match the target platform +## Anti-Patterns + +- [ ] Do not paraphrase original text when creating tracked deletions — the original text must be preserved exactly, character for character, or the tracked change cannot be reviewed against source +- [ ] Do not mix substantive changes with stylistic edits in the same section — reviewers need to approve substantive changes at a different threshold than copy edits +- [ ] Do not write margin comments as meta-commentary about the review process ("This section needs work") — comments must be actionable instructions the author can act on +- [ ] Do not flag every imperfect sentence as a change — over-redlining trains authors to accept changes without reading, which defeats the purpose of tracked review +- [ ] Do not produce a redline without a summary of top-level changes — reviewers read the summary first and use it to decide which changes to scrutinise in detail + ## Example Trigger Phrases - "Redline this contract" - "Create tracked changes for this document" diff --git a/plugins/pm-essentials/skills/meeting-notes/SKILL.md b/plugins/pm-essentials/skills/meeting-notes/SKILL.md index 8e6a394..5e3b6ab 100644 --- a/plugins/pm-essentials/skills/meeting-notes/SKILL.md +++ b/plugins/pm-essentials/skills/meeting-notes/SKILL.md @@ -7,6 +7,14 @@ description: "Structure and format meeting notes following PM best practices. Us This skill structures meeting notes to maximize value and ensure follow-through. +## Required Inputs + +Ask the user for these if not provided: +- **Meeting title and date** +- **Attendees** (names and roles) +- **Raw notes or transcript** (paste discussion notes, a transcript, or describe what was discussed) +- **Meeting type** (1:1 / sprint planning / product review / stakeholder sync / other) — determines which template to use + ## Standard Meeting Notes Template ### Meeting Header @@ -251,6 +259,14 @@ Template additions: - [ ] Open questions have an owner and a "by when" - [ ] No verbatim transcripts — synthesis only +## Anti-Patterns + +- [ ] Do not assign action items to "the team" or "everyone" — every action item must have exactly one named owner or it will not be completed +- [ ] Do not capture verbatim transcript content — meeting notes record decisions and commitments, not the full conversational path to get there +- [ ] Do not omit the context for decisions — a decision without its rationale is useless when someone asks "why did we do that?" six months later +- [ ] Do not leave open questions without an owner and deadline — an unanswered question with no follow-up assigned is a blocked decision +- [ ] Do not delay sending notes beyond 2 hours after the meeting — notes sent the next day miss the window when action item owners can act on commitments while fresh + ## Notes Distribution **Subject Line Format**: "[Meeting Type] Notes - [Date] - [Key Topic]" diff --git a/plugins/pm-essentials/skills/prd-template/SKILL.md b/plugins/pm-essentials/skills/prd-template/SKILL.md index 023daa1..542c342 100644 --- a/plugins/pm-essentials/skills/prd-template/SKILL.md +++ b/plugins/pm-essentials/skills/prd-template/SKILL.md @@ -110,6 +110,14 @@ Format: "As a [user type], I want to [action] so that [benefit]" - [ ] Open questions are listed explicitly - [ ] Implementation plan distinguishes MVP from future phases +## Anti-Patterns + +- [ ] Do not write requirements from the company's perspective — every requirement must trace back to a user need +- [ ] Do not include vague requirements like "the system should be fast" — every requirement must be testable +- [ ] Do not conflate MVP with future phases — be explicit about what is and is not in scope for the first release +- [ ] Do not leave success metrics as percentages without baselines — specify the current state and the target +- [ ] Do not skip open questions — unresolved assumptions are risks; surfacing them is the PM's job + ## Example PRD Opening ``` diff --git a/plugins/pm-essentials/skills/stakeholder-update/SKILL.md b/plugins/pm-essentials/skills/stakeholder-update/SKILL.md index d4cd429..87c1a9b 100644 --- a/plugins/pm-essentials/skills/stakeholder-update/SKILL.md +++ b/plugins/pm-essentials/skills/stakeholder-update/SKILL.md @@ -234,3 +234,11 @@ Only include issues that matter at executive level. - [ ] Every risk has a mitigation and a "help needed" flag if stakeholder action is required - [ ] Decisions needed have specific options and a clear recommendation - [ ] Total length is under 1 page / 2 minutes reading time + +## Anti-Patterns + +- [ ] Do not bury the status assessment at the bottom — BLUF means the most important information comes first +- [ ] Do not report metrics without a target or prior-period comparison — raw numbers without context are not useful +- [ ] Do not list risks without mitigation actions and clear flags for stakeholder help needed +- [ ] Do not write decisions needed as questions without providing a clear recommendation — executives need options, not open-ended questions +- [ ] Do not allow the update to exceed one page — if it requires more, the message needs editing, not expanding diff --git a/plugins/pm-essentials/skills/user-research-synthesis/SKILL.md b/plugins/pm-essentials/skills/user-research-synthesis/SKILL.md index 136324a..e219d5b 100644 --- a/plugins/pm-essentials/skills/user-research-synthesis/SKILL.md +++ b/plugins/pm-essentials/skills/user-research-synthesis/SKILL.md @@ -123,21 +123,21 @@ Research gaps identified: - Quantify when possible ("7 out of 10 users...") - Connect themes to business objectives -## Quality Standards +## Quality Checks -✅ **Good Synthesis:** -- Identifies patterns, not just individual responses -- Connects insights to product decisions -- Includes supporting evidence for each claim -- Separates observations from interpretations -- Prioritizes findings by impact +- [ ] Themes identify patterns across multiple participants, not individual responses +- [ ] Insights connect to specific product decisions, not just observations +- [ ] Each claim includes supporting evidence (quotes, counts, or examples) +- [ ] Observations and interpretations are clearly separated +- [ ] Findings are prioritised by impact, not just listed -❌ **Poor Synthesis:** -- Lists every individual comment -- Lacks evidence or examples -- Makes unsupported leaps -- Focuses on solutions before understanding problems -- Ignores contradictory data +## Anti-Patterns + +- [ ] Do not list every individual comment — synthesis must identify patterns across participants +- [ ] Do not make interpretive leaps without supporting evidence from the data +- [ ] Do not focus on feature requests before understanding the underlying problem — always identify the job-to-be-done first +- [ ] Do not ignore contradictory data — conflicting findings must be surfaced and noted +- [ ] Do not present results without quantifying prevalence — state how many participants held each view ## Example Theme diff --git a/plugins/pm-figma/skills/figma-annotation-guide/SKILL.md b/plugins/pm-figma/skills/figma-annotation-guide/SKILL.md index 3879ff9..804aa81 100644 --- a/plugins/pm-figma/skills/figma-annotation-guide/SKILL.md +++ b/plugins/pm-figma/skills/figma-annotation-guide/SKILL.md @@ -56,6 +56,14 @@ Touch targets, screen reader labels, focus order, colour contrast, motion prefer - [ ] Empty states specified - [ ] Edge cases listed as actionable questions +## Anti-Patterns + +- [ ] Do not annotate only the happy path — error states, loading states, and empty states must all be documented +- [ ] Do not use vague spacing descriptions like "some padding" — specify exact pixel values or token names +- [ ] Do not skip accessibility annotations — focus order, ARIA labels, and colour contrast ratios must be included +- [ ] Do not leave interaction behaviour undescribed — every interactive element needs a documented response +- [ ] Do not produce annotations without edge cases — developers need to know what happens at boundaries + ## Example Trigger Phrases - "Write dev annotations for this Figma screen" - "Create developer handoff notes for [screen/component]" diff --git a/plugins/pm-figma/skills/figma-component-audit/SKILL.md b/plugins/pm-figma/skills/figma-component-audit/SKILL.md index 4547ace..b525586 100644 --- a/plugins/pm-figma/skills/figma-component-audit/SKILL.md +++ b/plugins/pm-figma/skills/figma-component-audit/SKILL.md @@ -66,6 +66,14 @@ Naming convention to enforce: - [ ] Fix plan is ordered by impact-to-effort ratio - [ ] Variant completeness covers all interactive states +## Anti-Patterns + +- [ ] Do not flag naming issues without providing a specific, consistent naming convention to adopt +- [ ] Do not audit only visual consistency — also check for missing interactive states and accessibility compliance +- [ ] Do not list all issues at equal priority — group by impact (Critical / Major / Minor) so the fix plan is actionable +- [ ] Do not omit variant completeness — every interactive component must cover all required states +- [ ] Do not leave coverage gaps without recommending specific missing components to add + ## Example Trigger Phrases - "Audit my Figma component library" - "Review our design system for consistency issues" diff --git a/plugins/pm-figma/skills/figma-design-brief/SKILL.md b/plugins/pm-figma/skills/figma-design-brief/SKILL.md index 58d0f5e..e32c8a6 100644 --- a/plugins/pm-figma/skills/figma-design-brief/SKILL.md +++ b/plugins/pm-figma/skills/figma-design-brief/SKILL.md @@ -60,6 +60,14 @@ Feature, PM, Designer, Platform, Design due, Dev handoff dates. - [ ] Constraints include accessibility requirements - [ ] Open questions have owners +## Anti-Patterns + +- [ ] Do not write a design brief that describes the solution — the brief must describe the problem and constraints, not the design answer +- [ ] Do not skip the success criteria — designers need to know what "done" looks like before starting +- [ ] Do not omit existing components to reuse — briefs that ignore the design system lead to inconsistent implementations +- [ ] Do not leave open questions unresolved — escalate them before design work starts, not during it +- [ ] Do not confuse requirements with design instructions — the brief defines what, not how + ## Example Trigger Phrases - "Write a design brief for [feature]" - "Turn this PRD into a Figma design brief" diff --git a/plugins/pm-figma/skills/figma-design-critique-pm/SKILL.md b/plugins/pm-figma/skills/figma-design-critique-pm/SKILL.md index f00abf1..5c53f1d 100644 --- a/plugins/pm-figma/skills/figma-design-critique-pm/SKILL.md +++ b/plugins/pm-figma/skills/figma-design-critique-pm/SKILL.md @@ -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" diff --git a/plugins/pm-figma/skills/figma-design-qa/SKILL.md b/plugins/pm-figma/skills/figma-design-qa/SKILL.md index a78dc87..0f6a50f 100644 --- a/plugins/pm-figma/skills/figma-design-qa/SKILL.md +++ b/plugins/pm-figma/skills/figma-design-qa/SKILL.md @@ -1,6 +1,6 @@ --- name: figma-design-qa -description: "Run a pre-handoff QA checklist on any Figma design before it goes to engineering. Use when asked to QA a Figma design, do a pre-handoff check, review a design before engineering, or validate a Figma file is ready to build. Produces a structured QA checklist covering file hygiene, component usage, accessibility, and handoff readiness with pass/fail status. Optimised for Opus 4.7 and newer models." +description: "Runs a pre-handoff QA checklist on a Figma design before it goes to engineering. Use when asked to QA a Figma design, do a pre-handoff check, or validate a Figma file is ready to build. Produces a structured QA report covering file hygiene, component usage, accessibility, and handoff readiness with explicit pass/fail status per item. Optimised for Opus 4.7 and newer models." --- # Figma Design QA Skill @@ -81,6 +81,14 @@ Status, signed off by, date. - [ ] Blocking issues separated from minor ones - [ ] Handoff decision is explicit +## Anti-Patterns + +- [ ] Do not produce a partial QA — every checklist category must be evaluated, not just the ones that are obviously problematic +- [ ] Do not leave the handoff decision ambiguous — the output must explicitly state pass, pass with conditions, or fail +- [ ] Do not skip accessibility checks — colour contrast, tap target size, and screen reader labels are required, not optional +- [ ] Do not report issues without specifying which screen or component they appear on +- [ ] Do not approve a design if any component is detached from the library without a documented reason + ## Example Trigger Phrases - "QA this Figma design before handoff" - "Run a pre-handoff check on [feature] design" diff --git a/plugins/pm-figma/skills/figma-design-review/SKILL.md b/plugins/pm-figma/skills/figma-design-review/SKILL.md index 07ef102..fe01744 100644 --- a/plugins/pm-figma/skills/figma-design-review/SKILL.md +++ b/plugins/pm-figma/skills/figma-design-review/SKILL.md @@ -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]" diff --git a/plugins/pm-figma/skills/figma-prototype-plan/SKILL.md b/plugins/pm-figma/skills/figma-prototype-plan/SKILL.md index 01a3a05..534c931 100644 --- a/plugins/pm-figma/skills/figma-prototype-plan/SKILL.md +++ b/plugins/pm-figma/skills/figma-prototype-plan/SKILL.md @@ -76,6 +76,14 @@ Success when: [Specific trigger] - [ ] Success criteria defined for each task - [ ] Reset process defined for between participants +## Anti-Patterns + +- [ ] Do not prototype everything — scope must be limited to the interactions that answer the specific research questions +- [ ] Do not design prototype flows without also writing the test task scripts — the two must align exactly +- [ ] Do not skip the reset process between participants — unsettled prototype state contaminates results +- [ ] Do not plan a prototype without specifying which interactions are clickable vs static — ambiguity causes scope creep +- [ ] Do not scope a prototype without first defining the research questions it needs to answer + ## Example Trigger Phrases - "Plan the Figma prototype for our user test on [feature]" - "What interactions do I need to build for this prototype?" diff --git a/plugins/pm-figma/skills/figma-spacing-system/SKILL.md b/plugins/pm-figma/skills/figma-spacing-system/SKILL.md index 3efbe32..ad52872 100644 --- a/plugins/pm-figma/skills/figma-spacing-system/SKILL.md +++ b/plugins/pm-figma/skills/figma-spacing-system/SKILL.md @@ -69,6 +69,14 @@ Desktop (1440px): 12 columns, margin [value], gutter [value], max content width - [ ] Component conventions cover common decisions - [ ] Figma implementation steps included +## Anti-Patterns + +- [ ] Do not create a spacing scale with arbitrary values — the scale must follow a consistent mathematical ratio (e.g. 4px base, 8-4-2 system) +- [ ] Do not define spacing tokens without Figma implementation instructions — token names alone are not actionable +- [ ] Do not create a spacing system that doesn't account for component-level spacing conventions — global tokens and component usage must both be documented +- [ ] Do not skip grid definitions — spacing without a grid system is incomplete layout foundation documentation +- [ ] Do not produce a spacing system that ignores responsive behaviour — define how spacing adapts across breakpoints + ## Example Trigger Phrases - "Create a spacing system for our Figma design system" - "Define our spacing tokens for Figma" diff --git a/plugins/pm-figma/skills/figma-user-flow-planner/SKILL.md b/plugins/pm-figma/skills/figma-user-flow-planner/SKILL.md index da86767..80366c2 100644 --- a/plugins/pm-figma/skills/figma-user-flow-planner/SKILL.md +++ b/plugins/pm-figma/skills/figma-user-flow-planner/SKILL.md @@ -68,6 +68,14 @@ Feature name/ - [ ] Out-of-scope section is explicit - [ ] Figma file structure matches screen map +## Anti-Patterns + +- [ ] Do not plan only the happy path — all error states, empty states, and edge cases must be mapped before designing starts +- [ ] Do not produce a flow map that doesn't match the Figma file structure — the page structure must reflect the flow map +- [ ] Do not define screens without specifying all required states — a screen without its variants is an incomplete design scope +- [ ] Do not start designing before entry and exit points are fully documented — unclear boundaries cause scope creep +- [ ] Do not plan user flows without tying each step back to a user goal — every screen must justify its existence + ## Example Trigger Phrases - "Plan the user flow for [feature] in Figma" - "What screens do I need to design for [feature]?" diff --git a/plugins/pm-figma/skills/figma-variant-matrix/SKILL.md b/plugins/pm-figma/skills/figma-variant-matrix/SKILL.md index bc61663..b2e22d7 100644 --- a/plugins/pm-figma/skills/figma-variant-matrix/SKILL.md +++ b/plugins/pm-figma/skills/figma-variant-matrix/SKILL.md @@ -70,6 +70,14 @@ For each state, list only what changes from Default: - [ ] Token mapping covers all visual properties - [ ] Disabled state uses layer-level properties not opacity +## Anti-Patterns + +- [ ] Do not create a variant matrix with properties that overlap or conflict — each property must be independently variable +- [ ] Do not use opacity for disabled states — disabled states must use layer-level properties, not opacity +- [ ] Do not enumerate every mathematical combination if many are invalid — document only valid, buildable combinations +- [ ] Do not define variants without considering responsive behaviour — specify which properties change across screen sizes +- [ ] Do not produce a matrix without Figma implementation guidance — variant naming conventions must follow Figma's property system + ## Example Trigger Phrases - "Define the variants for a [component] in Figma" - "What states does my [component] need?" diff --git a/plugins/pm-finance/skills/budget-variance-analysis/SKILL.md b/plugins/pm-finance/skills/budget-variance-analysis/SKILL.md index a42abc9..3ffcdda 100644 --- a/plugins/pm-finance/skills/budget-variance-analysis/SKILL.md +++ b/plugins/pm-finance/skills/budget-variance-analysis/SKILL.md @@ -48,10 +48,17 @@ Does the full-year forecast need updating? State revised expectation and key ass 3-4 sentences of management commentary suitable for a board pack. ## Quality Checks -- All variances above threshold explained -- Root causes specific (not vague) -- Favourable/Adverse correctly labelled -- Forecast impact stated for material variances +- [ ] All variances above threshold explained +- [ ] Root causes specific (not vague) +- [ ] Favourable/Adverse correctly labelled +- [ ] Forecast impact stated for material variances + +## Anti-Patterns + +- [ ] Do not explain a variance as "timing" without specifying which period it will reverse into and what amount is expected +- [ ] Do not label a favourable variance on a cost line without checking whether it is due to underspend, delayed spend, or reduced activity — the cause determines whether it is genuinely good news +- [ ] Do not omit variances below the materiality threshold entirely — note them collectively so the reader knows they exist and were reviewed +- [ ] Do not present a variance analysis without a forecast impact statement for material items — historical variances without forward implications are incomplete ## Example Trigger Phrases - "Write a variance analysis for these actuals vs budget: [paste]" diff --git a/plugins/pm-finance/skills/financial-due-diligence/SKILL.md b/plugins/pm-finance/skills/financial-due-diligence/SKILL.md index f8f0c94..5727127 100644 --- a/plugins/pm-finance/skills/financial-due-diligence/SKILL.md +++ b/plugins/pm-finance/skills/financial-due-diligence/SKILL.md @@ -70,6 +70,22 @@ Produces a structured financial due diligence framework — document request lis - Balance sheet risk: [Assessment] - Overall: Green Strong / Amber Acceptable / Red Material concerns +## Quality Checks + +- [ ] Document request list is tailored to the transaction type and stage — not a generic template +- [ ] Red flags checklist covers revenue quality, margins, cash conversion, and balance sheet risk +- [ ] Every analytical question connects to a specific risk the transaction presents +- [ ] Summary output template is completed with an overall RAG assessment +- [ ] Disclaimer that this is a framework and does not substitute for qualified financial or legal advice + +## Anti-Patterns + +- [ ] Do not present the checklist without tailoring it to the specific transaction type and stage of diligence +- [ ] Do not overlook revenue concentration risk — customer concentration above 20–30% is a material risk that must be flagged +- [ ] Do not confuse EBITDA with cash — always check cash conversion and identify non-cash items +- [ ] Do not skip the related-party transaction review — undisclosed related-party dealings are a common due diligence failure point +- [ ] Do not produce output without noting this is a framework and qualified financial and legal advice is required + ## Example Trigger Phrases - "Give me a financial due diligence checklist for [company type]" - "What documents should I request for financial DD?" diff --git a/plugins/pm-finance/skills/financial-model-narrative/SKILL.md b/plugins/pm-finance/skills/financial-model-narrative/SKILL.md index a84b630..ad97276 100644 --- a/plugins/pm-finance/skills/financial-model-narrative/SKILL.md +++ b/plugins/pm-finance/skills/financial-model-narrative/SKILL.md @@ -63,6 +63,14 @@ For each significant variance: - [ ] Audience-appropriate language (board vs investor vs management) - [ ] One-off items clearly distinguished from recurring items +## Anti-Patterns + +- [ ] Do not list numbers without explaining what is driving them — narrative must go beyond restating the figures +- [ ] Do not mix one-off items with recurring performance without clearly distinguishing them +- [ ] Do not write the same level of detail for all line items — focus depth on the items that matter most +- [ ] Do not omit forward-looking commentary — a narrative without outlook is incomplete for board or investor audiences +- [ ] Do not use technical accounting language without translation — the audience is executives, not accountants + ## Example Trigger Phrases - "Write a financial narrative for these results: [paste numbers]" - "Turn this P&L into a board narrative" diff --git a/plugins/pm-finance/skills/investor-pitch-deck/SKILL.md b/plugins/pm-finance/skills/investor-pitch-deck/SKILL.md index 677fcaa..83f53e8 100644 --- a/plugins/pm-finance/skills/investor-pitch-deck/SKILL.md +++ b/plugins/pm-finance/skills/investor-pitch-deck/SKILL.md @@ -51,6 +51,14 @@ For each slide: - [ ] Ask slide specifies use of funds and 18-month milestones - [ ] TAM is bottoms-up where possible +## Anti-Patterns + +- [ ] Do not include a "no real competitors" slide — every company has competition and investors will discount founders who claim otherwise +- [ ] Do not use a top-down TAM calculation without a bottoms-up validation — investors distrust pure top-down market sizing +- [ ] Do not leave the ask vague — specify the amount, use of funds, and 18-month milestones the funding enables +- [ ] Do not let traction slides show vanity metrics — focus on revenue, retention, and growth rate over downloads and signups +- [ ] Do not bury the problem slide — investors must understand and feel the pain before they care about the solution + ## Example Trigger Phrases - "Build a pitch deck structure for [company]" - "Help me structure my Series A deck" diff --git a/plugins/pm-finance/skills/tax-planning-checklist/SKILL.md b/plugins/pm-finance/skills/tax-planning-checklist/SKILL.md index 76e3103..633736a 100644 --- a/plugins/pm-finance/skills/tax-planning-checklist/SKILL.md +++ b/plugins/pm-finance/skills/tax-planning-checklist/SKILL.md @@ -120,6 +120,14 @@ Based on the above, prioritise these before year-end: - [ ] Disclaimer is prominent — this is a framework, not tax advice - [ ] Threshold figures are flagged as requiring verification for current tax year +## Anti-Patterns + +- [ ] Do not provide specific tax advice — always recommend qualified tax advice and note this prominently +- [ ] Do not present threshold figures as definitive without noting they require verification for the current tax year +- [ ] Do not produce a generic checklist without tailoring it to the entity type (individual, sole trader, limited company) +- [ ] Do not omit timing-critical items — some reliefs require action before year-end and deadlines must be called out +- [ ] Do not conflate UK and non-UK tax rules — clarify jurisdiction before generating any checklist + ## Example Trigger Phrases - "Give me a tax planning checklist for [year-end / my situation]" diff --git a/plugins/pm-gtm/skills/competitor-teardown/SKILL.md b/plugins/pm-gtm/skills/competitor-teardown/SKILL.md index 0c5af25..23409d2 100644 --- a/plugins/pm-gtm/skills/competitor-teardown/SKILL.md +++ b/plugins/pm-gtm/skills/competitor-teardown/SKILL.md @@ -70,6 +70,13 @@ Produce a clean SWOT for the user's product in the context of this competitive l - [ ] SWOT is honest — Weaknesses and Threats should not be softened - [ ] Recommendations are specific and actionable, not generic strategy advice +## Anti-Patterns + +- [ ] Do not mark feature presence as equivalent across competitors without noting quality differences — both products may have "reporting" while one's is meaningfully better +- [ ] Do not position the user's product in the most favourable quadrant without justification — a self-serving positioning map that ignores real competitive pressure provides no strategic value +- [ ] Do not soften Weaknesses or Threats in the SWOT — a SWOT that only celebrates strengths is a marketing document, not a strategy tool +- [ ] Do not include unverifiable claims about competitor capabilities without flagging them as assumptions — presenting rumours as facts damages analytical credibility + ## Example Trigger Phrases - "Do a competitor analysis of [Product] vs [Competitor A] and [Competitor B]" diff --git a/plugins/pm-gtm/skills/content-calendar/SKILL.md b/plugins/pm-gtm/skills/content-calendar/SKILL.md index 88d0452..f68f3d6 100644 --- a/plugins/pm-gtm/skills/content-calendar/SKILL.md +++ b/plugins/pm-gtm/skills/content-calendar/SKILL.md @@ -50,6 +50,14 @@ For each "High Priority" post, add one repurposing suggestion — e.g. "Turn thi - [ ] Formats match platform norms - [ ] Repurposing map covers all High Priority posts +## Anti-Patterns + +- [ ] Do not fill the calendar with generic topic placeholders — every entry must have a specific, usable topic and hook +- [ ] Do not stack the same pillar or format on consecutive days — variety is required +- [ ] Do not produce opening hooks that start with "Did you know" or other cliché openers +- [ ] Do not ignore channel norms — formats must match the platform (no long-form threads for Instagram) +- [ ] Do not skip the repurposing map for High Priority posts + ## Example Trigger Phrases - "Build me a 4-week content calendar for [brand]" diff --git a/plugins/pm-gtm/skills/email-campaign/SKILL.md b/plugins/pm-gtm/skills/email-campaign/SKILL.md index 9d0c852..e95784a 100644 --- a/plugins/pm-gtm/skills/email-campaign/SKILL.md +++ b/plugins/pm-gtm/skills/email-campaign/SKILL.md @@ -70,6 +70,14 @@ For every email in the sequence, produce: - [ ] Tone is consistent across all emails - [ ] Strategic notes explain the intent of each email +## Anti-Patterns + +- [ ] Do not include more than one primary CTA per email — competing calls to action reduce click-through by splitting attention +- [ ] Do not open with "Hi, welcome to [product]" or any variation of a generic greeting — the opening line must earn attention immediately or recipients stop reading +- [ ] Do not write preview text that repeats the subject line — preview text is a second chance to earn the open, not a repeat of the first chance +- [ ] Do not write a sequence where each email restates the same value proposition — each email must advance the narrative or serve a distinct purpose in the buyer's journey +- [ ] Do not assume all subscribers receive all emails — each email must stand alone for subscribers who missed earlier messages in the sequence + ## Example Trigger Phrases - "Write a 3-email launch sequence for [product]" diff --git a/plugins/pm-gtm/skills/go-to-market/SKILL.md b/plugins/pm-gtm/skills/go-to-market/SKILL.md index af6df9d..54131a2 100644 --- a/plugins/pm-gtm/skills/go-to-market/SKILL.md +++ b/plugins/pm-gtm/skills/go-to-market/SKILL.md @@ -89,6 +89,14 @@ Before delivering output, verify: - [ ] Use cases include a Before/After structure - [ ] Language is consistent with the target customer's vocabulary (not internal engineering terms) +## Anti-Patterns + +- [ ] Do not write feature descriptions instead of benefits — the GTM pack must translate features into customer value +- [ ] Do not use the same messaging across all buyer personas — each role has different priorities and language +- [ ] Do not create a positioning statement that could apply to any competitor — differentiation must be specific and defensible +- [ ] Do not skip the "not for" section — defining who this is not for sharpens positioning and prevents misdirected sales effort +- [ ] Do not list use cases without tying them to specific job titles or buyer roles + ## Example Trigger Phrases - "Create a positioning statement for [product]" diff --git a/plugins/pm-gtm/skills/media-pitch/SKILL.md b/plugins/pm-gtm/skills/media-pitch/SKILL.md index 3fcb0ca..8c8da14 100644 --- a/plugins/pm-gtm/skills/media-pitch/SKILL.md +++ b/plugins/pm-gtm/skills/media-pitch/SKILL.md @@ -76,6 +76,14 @@ If the user doesn't have a strong angle, help them find one: - [ ] Journalist's name is used (not "Hi there") - [ ] Mobile number included for deadline follow-up +## Anti-Patterns + +- [ ] Do not write a pitch that leads with the company's history or description — the story angle must come first, not who the company is +- [ ] Do not use vague data points ("significant growth", "thousands of users") — every statistic must be specific and verifiable +- [ ] Do not send the same pitch to multiple journalists in a BCC — pitches must be individually tailored to each journalist's beat and recent work +- [ ] Do not offer an exclusive without setting a response deadline — an open-ended exclusive invitation is ignored or used to delay indefinitely +- [ ] Do not follow up with "just checking in" — a follow-up must contain new information or a fresh angle, otherwise it is noise + ## Example Trigger Phrases - "Write a media pitch for [story or announcement]" diff --git a/plugins/pm-gtm/skills/product-positioning-doc/SKILL.md b/plugins/pm-gtm/skills/product-positioning-doc/SKILL.md index 7640161..bb43044 100644 --- a/plugins/pm-gtm/skills/product-positioning-doc/SKILL.md +++ b/plugins/pm-gtm/skills/product-positioning-doc/SKILL.md @@ -212,6 +212,14 @@ Positioning only works if it's implemented consistently: - [ ] Persona messaging uses the buyer's language, not the company's - [ ] At least two people from product, marketing, and sales have reviewed and approved +## Anti-Patterns + +- [ ] Do not write positioning that could describe any competitor — differentiation must be specific, provable, and hard to copy +- [ ] Do not mix category design with category entry — know whether you are creating a new category or competing in an existing one +- [ ] Do not create persona messaging that uses the same headline for all personas — each persona has different priorities +- [ ] Do not include proof points that are claims without evidence — every proof point needs a supporting data point or reference +- [ ] Do not skip the "not for" section — defining who this is not for sharpens targeting and prevents off-persona deals + ## Example Trigger Phrases - "Write a positioning document for [product]" diff --git a/plugins/pm-gtm/skills/seo-content-brief/SKILL.md b/plugins/pm-gtm/skills/seo-content-brief/SKILL.md index 8fea7bd..4589f74 100644 --- a/plugins/pm-gtm/skills/seo-content-brief/SKILL.md +++ b/plugins/pm-gtm/skills/seo-content-brief/SKILL.md @@ -124,3 +124,11 @@ Each heading is the exact H2/H3 to use (these are what Google reads): - "Create a content brief for [topic]" - "What should I include in a blog post about [keyword]?" - "Build a content strategy brief for [topic]" + +## Anti-Patterns + +- [ ] Do not write an outline that answers a different question than the actual search intent — the brief must match what the searcher wants, not what the brand wants to say +- [ ] Do not set keyword density targets so high that they produce unnatural writing — 3–5 natural mentions is guidance, not a quota +- [ ] Do not skip the competitor gap analysis — without it, the brief produces content that duplicates what already ranks +- [ ] Do not leave the FAQ section without real "People Also Ask" questions — fabricated questions miss search volume opportunities +- [ ] Do not write a title tag longer than 60 characters — it will be truncated in search results and undermine ranking diff --git a/plugins/pm-gtm/skills/social-media-strategy/SKILL.md b/plugins/pm-gtm/skills/social-media-strategy/SKILL.md index 7966e53..efe18c3 100644 --- a/plugins/pm-gtm/skills/social-media-strategy/SKILL.md +++ b/plugins/pm-gtm/skills/social-media-strategy/SKILL.md @@ -235,3 +235,11 @@ A concrete first month of content — ready to adapt and post: - "Help me define content pillars and posting cadence for our startup" - "Design a 90-day social media plan for [company]" - "What should our social media strategy be for a product launch?" + +## Anti-Patterns + +- [ ] Do not recommend every platform — justify each choice with where the target audience actually spends time +- [ ] Do not define content pillars that serve only the brand — each pillar must deliver specific value to the audience or it will not earn attention +- [ ] Do not set a posting cadence that exceeds the team's realistic capacity — an unsustainable strategy fails faster than a modest one +- [ ] Do not use vanity metrics (likes, followers in isolation) as primary KPIs — tie KPIs to the stated business goal +- [ ] Do not skip the tone of voice section — without it, multiple contributors produce inconsistent content that erodes brand identity diff --git a/plugins/pm-hr/skills/change-management-plan/SKILL.md b/plugins/pm-hr/skills/change-management-plan/SKILL.md index cd87e16..9dc8984 100644 --- a/plugins/pm-hr/skills/change-management-plan/SKILL.md +++ b/plugins/pm-hr/skills/change-management-plan/SKILL.md @@ -131,6 +131,14 @@ Ask the user for these if not provided: - [ ] Adoption metrics have a measurement date and owner - [ ] Resistance management has specific responses (not just "communicate more") +## Anti-Patterns + +- [ ] Do not treat communication as a one-time announcement — people need to hear a message multiple times before they internalise it; plan for repeated touchpoints +- [ ] Do not assign change management to a single owner without involving line managers — managers are the most effective cascade channel and must be briefed before their teams +- [ ] Do not schedule training after go-live — people who learn a new system on the day they need to use it will revert to the old process +- [ ] Do not ignore resistors in the stakeholder analysis — resistors who are not explicitly engaged will undermine adoption, especially informal leaders +- [ ] Do not measure adoption only at go-live — the real test is sustained adoption at 90 days, when novelty has worn off + ## Example Trigger Phrases - "Write a change management plan for [initiative]" diff --git a/plugins/pm-hr/skills/employee-engagement-survey/SKILL.md b/plugins/pm-hr/skills/employee-engagement-survey/SKILL.md index b2003dd..e7de987 100644 --- a/plugins/pm-hr/skills/employee-engagement-survey/SKILL.md +++ b/plugins/pm-hr/skills/employee-engagement-survey/SKILL.md @@ -7,6 +7,18 @@ description: "Design an employee engagement survey and analyse results. Use when Designs complete employee engagement surveys and provides a framework for analysing and acting on results. +## Required Inputs + +Ask the user for these if not provided: +- **Mode** — designing a new survey or analysing existing results +- **Survey type** (annual / quarterly pulse / post-onboarding / exit / specific topic) +- **Company name** (for personalisation of question text) +- **Company size and stage** (startup / scaleup / enterprise — affects question relevance) +- **Key areas of concern** (optional — e.g. "we have had high attrition on the engineering team") +- **Anonymity approach** — fully anonymous, team-level reporting only, or individual responses visible to HR +- **Length target** (short: 5–10 questions / standard: 15–25 / comprehensive: 30+) +- **For analysis mode:** survey results data (paste as table, CSV, or summary statistics) + ## Mode Detection - User provides survey results -> Analysis mode - User wants to create a survey -> Design mode @@ -88,6 +100,14 @@ eNPS: Below 0 = Concerning / 0-30 = Good / 30-70 = Great / 70+ = Excellent - [ ] Analysis includes a specific action planning template (not just observations) - [ ] Results communication template commits to sharing back with employees by a specific date +## Anti-Patterns + +- [ ] Do not launch a survey without committing to a communication-back date — surveys with no follow-through reduce trust and depress future response rates +- [ ] Do not use only Likert scale questions — open-text responses surface specific themes that quantitative scores cannot, and are essential for action planning +- [ ] Do not design a comprehensive 30+ question survey as a pulse — pulse surveys that take more than 5 minutes see sharply lower completion rates +- [ ] Do not present analysis without an action planning template — raw scores without committed actions are the most common reason engagement survey data is ignored +- [ ] Do not segment results below teams of 5 when anonymity is promised — small-group breakdowns allow individual identification and destroy psychological safety + ## Example Trigger Phrases - "Create an employee engagement survey for our team" - "Design a pulse survey for [topic]" diff --git a/plugins/pm-hr/skills/job-description-writer/SKILL.md b/plugins/pm-hr/skills/job-description-writer/SKILL.md index effc6f5..94dd074 100644 --- a/plugins/pm-hr/skills/job-description-writer/SKILL.md +++ b/plugins/pm-hr/skills/job-description-writer/SKILL.md @@ -68,6 +68,14 @@ Nice to have (3-4 items): - [ ] Inclusive language review completed - [ ] No years-of-experience requirements unless legally required +## Anti-Patterns + +- [ ] Do not include years-of-experience requirements unless legally necessary — they exclude qualified candidates and may create legal risk +- [ ] Do not list "nice to have" items in the requirements section — separate mandatory from desirable clearly +- [ ] Do not use gendered or exclusionary language — run the inclusive language check before finalising +- [ ] Do not write a responsibilities section with more than 8 items — prioritise the most important duties +- [ ] Do not omit compensation range where legally required or culturally expected — hiding salary deters qualified candidates + ## Example Trigger Phrases - "Write a job description for a [role]" - "Create an inclusive job posting for [role]" diff --git a/plugins/pm-hr/skills/onboarding-plan/SKILL.md b/plugins/pm-hr/skills/onboarding-plan/SKILL.md index 46865eb..8746198 100644 --- a/plugins/pm-hr/skills/onboarding-plan/SKILL.md +++ b/plugins/pm-hr/skills/onboarding-plan/SKILL.md @@ -91,6 +91,14 @@ New hire: Have the clarity, tools, support needed? What surprised you? What woul - [ ] Plan is tailored to the specific role and level (not generic) - [ ] Key stakeholder 1:1s are listed by name or role +## Anti-Patterns + +- [ ] Do not produce a generic plan that could apply to any role — the plan must reference the specific role, team, tools, and priorities provided, not use placeholder text +- [ ] Do not skip the Before Day 1 manager checklist — IT access and system provisioning failures on day 1 destroy first impressions and waste the new hire's first week +- [ ] Do not set milestones without distinguishing between the orient, learn, contribute, and lead phases — collapsing phases produces plans where new hires are expected to lead before they understand the product +- [ ] Do not omit the 90-day review questions — the review is the accountability mechanism for the entire plan, and skipping it makes the milestones meaningless +- [ ] Do not treat the plan as a task list — each phase should have a clear theme and a milestone that describes an observable capability, not just a set of completed activities + ## Example Trigger Phrases - "Create a 30/60/90 day plan for a new [role]" - "Write an onboarding plan for [name] starting as [role]" diff --git a/plugins/pm-hr/skills/redundancy-consultation/SKILL.md b/plugins/pm-hr/skills/redundancy-consultation/SKILL.md index 757e9e4..63254a2 100644 --- a/plugins/pm-hr/skills/redundancy-consultation/SKILL.md +++ b/plugins/pm-hr/skills/redundancy-consultation/SKILL.md @@ -71,6 +71,14 @@ WARNING: Take advice from an employment lawyer or qualified HR professional befo - [ ] Statutory redundancy pay guidance included - [ ] Legal advice disclaimer is prominent +## Anti-Patterns + +- [ ] Do not proceed without a prominent disclaimer that qualified HR and legal advice is required before taking any action +- [ ] Do not use template letters without customising them for the specific individual and situation +- [ ] Do not omit the genuine exploration of alternatives — redundancy consultation must consider alternatives before confirming decisions +- [ ] Do not leave out statutory redundancy pay guidance — employees have legal entitlements that must be referenced +- [ ] Do not conduct a redundancy process without documenting the selection criteria and scoring — undocumented decisions create legal risk + ## Example Trigger Phrases - "Help me structure a redundancy consultation" - "Draft an at-risk letter for [role]" diff --git a/plugins/pm-legal/skills/compliance-checklist/SKILL.md b/plugins/pm-legal/skills/compliance-checklist/SKILL.md index d260a14..22de863 100644 --- a/plugins/pm-legal/skills/compliance-checklist/SKILL.md +++ b/plugins/pm-legal/skills/compliance-checklist/SKILL.md @@ -99,6 +99,14 @@ Once certified/compliant, what needs to continue: - [ ] Quick wins clearly separated from complex implementations - [ ] Evidence requirements tied to specific controls +## Anti-Patterns + +- [ ] Do not omit the legal disclaimer — this checklist does not constitute compliance advice and must never be presented as a substitute for qualified professional review +- [ ] Do not generate a generic checklist that is not tailored to the stated framework, organisation type, and maturity level — a SOC 2 checklist for a startup and an enterprise are fundamentally different documents +- [ ] Do not list controls without specifying what evidence is required — a control without evidence requirements cannot be audited +- [ ] Do not mark a control as "full" implementation when it is partial — overestimating readiness leads to audit failures and regulatory risk +- [ ] Do not skip the "common pitfalls" section — this is where organisations most frequently fail audits for the stated framework + ## Example Trigger Phrases - "Create a GDPR compliance checklist for our SaaS" - "Generate a SOC 2 Type II readiness checklist" diff --git a/plugins/pm-legal/skills/contract-review/SKILL.md b/plugins/pm-legal/skills/contract-review/SKILL.md index f83533e..7566700 100644 --- a/plugins/pm-legal/skills/contract-review/SKILL.md +++ b/plugins/pm-legal/skills/contract-review/SKILL.md @@ -65,6 +65,14 @@ WARNING: This review is for informational purposes only and does not constitute - [ ] Plain English summary can be understood by a non-lawyer - [ ] Disclaimer is included +## Anti-Patterns + +- [ ] Do not provide legal advice or suggest the review substitutes for qualified legal counsel +- [ ] Do not skip flagging unusual or one-sided clauses because they appear standard +- [ ] Do not omit a plain-English summary — legal jargon alone is not useful output +- [ ] Do not rate risk without explaining what specifically drives that rating +- [ ] Do not ignore missing clauses — absence of key protections is itself a risk + ## Example Trigger Phrases - "Review this contract: [paste]" - "Flag the key risks in this agreement" diff --git a/plugins/pm-legal/skills/legal-brief/SKILL.md b/plugins/pm-legal/skills/legal-brief/SKILL.md index 1e5e496..a6a5c4b 100644 --- a/plugins/pm-legal/skills/legal-brief/SKILL.md +++ b/plugins/pm-legal/skills/legal-brief/SKILL.md @@ -65,6 +65,14 @@ WARNING: This draft requires review by a qualified legal professional. It does n - [ ] Caveats section lists what would change the analysis - [ ] Disclaimer is included +## Anti-Patterns + +- [ ] Do not present uncertain legal positions with confident language — areas of legal ambiguity must be flagged explicitly, not smoothed over +- [ ] Do not omit the disclaimer — every legal brief output must include the professional review caveat before the user treats it as advice +- [ ] Do not structure the brief chronologically — IRAC format (Issue, Rule, Application, Conclusion) must be used regardless of how the user framed the request +- [ ] Do not cite cases or statutes from memory without flagging them as [REQUIRES VERIFICATION] — hallucinated citations are worse than no citations +- [ ] Do not conflate jurisdiction — legal positions in England & Wales, US, and EU can differ materially; always confirm jurisdiction before stating the rule + ## Example Trigger Phrases - "Draft a legal memo on [issue]" - "Write a legal brief arguing [position]" diff --git a/plugins/pm-legal/skills/nda-analyser/SKILL.md b/plugins/pm-legal/skills/nda-analyser/SKILL.md index ca64772..1aab752 100644 --- a/plugins/pm-legal/skills/nda-analyser/SKILL.md +++ b/plugins/pm-legal/skills/nda-analyser/SKILL.md @@ -1,6 +1,6 @@ --- name: nda-analyser -description: "Analyse a Non-Disclosure Agreement (NDA) and flag key terms, unusual provisions, and negotiation points. Use when asked to review an NDA, mutual NDA, confidentiality agreement, or non-disclosure deed. Produces clause-by-clause analysis with risk flags and a negotiation checklist." +description: "Analyses a Non-Disclosure Agreement clause by clause and flags unusual terms, one-sided provisions, and negotiation points. Use when reviewing an NDA, mutual NDA, confidentiality agreement, or non-disclosure deed before signing or countering. Produces a plain English verdict, clause-by-clause risk analysis, and a prioritised negotiation checklist — always with a disclaimer that qualified legal advice is required before signing." --- # NDA Analyser Skill @@ -61,6 +61,14 @@ WARNING: This analysis is for informational purposes only and is not legal advic - [ ] Plain English verdict given (standard / one-sided / needs lawyer) - [ ] Disclaimer is included +## Anti-Patterns + +- [ ] Do not present the analysis as legal advice — the disclaimer must appear prominently and the output must recommend qualified legal review before any signing decision +- [ ] Do not skip the residuals clause check — residuals clauses allow the receiving party to use disclosed information from memory, which is one of the highest-risk provisions in any NDA +- [ ] Do not evaluate only the clauses explicitly flagged by the user — a complete analysis must cover all standard clause types even if the user only asked about one +- [ ] Do not assess breadth of the confidentiality definition without checking for oral disclosure coverage — oral disclosures with no written confirmation requirement are a common enforcement gap +- [ ] Do not omit the plain English verdict — a clause-by-clause analysis without a summary conclusion leaves the user unable to act on the findings + ## Example Trigger Phrases - "Analyse this NDA" - "Review this confidentiality agreement" diff --git a/plugins/pm-operations/skills/email-triage/SKILL.md b/plugins/pm-operations/skills/email-triage/SKILL.md index 87578c9..b3f09b1 100644 --- a/plugins/pm-operations/skills/email-triage/SKILL.md +++ b/plugins/pm-operations/skills/email-triage/SKILL.md @@ -1,6 +1,6 @@ --- name: email-triage -description: Reads your Gmail inbox for a configurable window (default: last 8 hours) and surfaces only what needs action — replies, decisions, or follow-up. Filters out receipts, notifications, newsletters, and anything that doesn't need you. +description: "Reads your Gmail inbox for a configurable window (default: last 8 hours) and surfaces only what needs action — replies, decisions, or follow-up. Filters out receipts, notifications, newsletters, and anything that doesn't need you." --- # Email Triage @@ -169,6 +169,14 @@ Keep this to one line. Do not elaborate. - [ ] Output is scannable — no unnecessary prose, no padding - [ ] Financial statements and sensitive content were counted but not shown in full +## Anti-Patterns + +- [ ] Do not surface FYI emails in the High or Medium priority sections — burying actionable items with informational ones defeats the purpose of triage +- [ ] Do not write vague "What they need" summaries ("Sarah sent an email about the report") — every summary must state the actual ask, not a description of the email +- [ ] Do not apply the same tone to every reply starter — a formal email from a client requires a different opener than a casual Slack-style email from a colleague +- [ ] Do not include emails outside the requested time window — time window accuracy is the core trust signal for this skill +- [ ] Do not omit the filtered-out count — users need to know how much was scanned, not just what was surfaced, to trust the triage is complete + ## Dispatch / Mobile Usage This skill works from the Claude mobile app (Dispatch). On mobile, the output renders cleanly with the emoji priority markers serving as visual anchors for quick scanning. Recommended mobile trigger: "Check my emails" or "/email-triage". diff --git a/plugins/pm-operations/skills/morning-intelligence/SKILL.md b/plugins/pm-operations/skills/morning-intelligence/SKILL.md index ef42251..af349fd 100644 --- a/plugins/pm-operations/skills/morning-intelligence/SKILL.md +++ b/plugins/pm-operations/skills/morning-intelligence/SKILL.md @@ -1,6 +1,6 @@ --- name: morning-intelligence -description: "Run a 15-question interview to capture your role, topics, sources, exclusions, and format preferences — then write a master prompt you can drop into a scheduled task or Claude Code Routine to get a personalised news brief every morning. Use when asked to set up a morning intelligence brief, build a morning news prompt, or create a personalised news briefing." +description: "Interviews you across 15 questions to capture your role, topics, sources, exclusions, and format preferences, then writes a master prompt you can paste into a scheduled task or Claude Code Routine. Use when you want to set up a personalised daily news brief, build a reusable morning news prompt, or create an automated intelligence briefing. Produces a confirmed summary of your preferences, a ready-to-paste master prompt, and setup instructions for both Cowork Scheduled Tasks and Claude Code Routines." --- # Morning Intelligence Skill @@ -185,6 +185,14 @@ UPDATING YOUR BRIEF - [ ] The master prompt is inside a code block so it copies cleanly - [ ] Both setup options (Cowork and Claude Code Routines) are included +## Anti-Patterns + +- [ ] Do not skip the interview and write a generic master prompt — a brief that is not tailored to the user's specific role and topics will be ignored after the first day +- [ ] Do not proceed to write the master prompt without confirming the "What I Heard" summary — errors in the summary will silently propagate into a prompt that produces the wrong briefing every morning +- [ ] Do not use broad topic labels in the master prompt (e.g. "AI", "tech news") — every topic must have a specific angle or focus to produce signal-to-noise ratio worth reading +- [ ] Do not omit the NEVER INCLUDE section — without explicit exclusions, the briefing will fill with noise that the user said they wanted filtered out +- [ ] Do not ask all 15 questions at once — the interview must run one question or small group at a time to produce specific, considered answers + --- ## Example Trigger Phrases diff --git a/plugins/pm-operations/skills/process-documentation/SKILL.md b/plugins/pm-operations/skills/process-documentation/SKILL.md index 937c8c9..e907edb 100644 --- a/plugins/pm-operations/skills/process-documentation/SKILL.md +++ b/plugins/pm-operations/skills/process-documentation/SKILL.md @@ -83,6 +83,14 @@ Next review due: [Date] - [ ] Escalation path is named (specific people or roles, not just "your manager") - [ ] Review date is set +## Anti-Patterns + +- [ ] Do not write steps without specifying who is responsible for each — ownership must be explicit throughout +- [ ] Do not omit the escalation path — every process must say what happens when something goes wrong +- [ ] Do not document the ideal process if the real process differs — document reality, then note improvements separately +- [ ] Do not skip edge cases and exceptions — they are where most process failures actually occur +- [ ] Do not produce documentation without a review date — undated process docs quickly become incorrect + ## Example Trigger Phrases - "Document this process: [description]" - "Write a process guide for [workflow]" diff --git a/plugins/pm-operations/skills/project-status-report/SKILL.md b/plugins/pm-operations/skills/project-status-report/SKILL.md index 9676ff3..d05e19c 100644 --- a/plugins/pm-operations/skills/project-status-report/SKILL.md +++ b/plugins/pm-operations/skills/project-status-report/SKILL.md @@ -111,6 +111,14 @@ RAG definitions: - [ ] Milestones are binary (complete or not complete — no "85% done") - [ ] Executive summary can stand alone for a stakeholder who reads nothing else +## Anti-Patterns + +- [ ] Do not rate project health as Green while listing unresolved critical blockers +- [ ] Do not report milestone progress as a percentage — milestones are binary: complete or not complete +- [ ] Do not bury risks at the bottom — if something is high risk, it belongs in the executive summary +- [ ] Do not leave decisions required without specifying who must decide and by when +- [ ] Do not write an executive summary that requires reading the full report to understand — it must stand alone + ## Example Trigger Phrases - "Write a project status report for [project]" - "Generate a RAG status update for [project]" diff --git a/plugins/pm-operations/skills/raci-matrix/SKILL.md b/plugins/pm-operations/skills/raci-matrix/SKILL.md index 7225a32..02e145a 100644 --- a/plugins/pm-operations/skills/raci-matrix/SKILL.md +++ b/plugins/pm-operations/skills/raci-matrix/SKILL.md @@ -151,6 +151,14 @@ Please review the full matrix here: [Link]. Raise any concerns by [Date] — aft - [ ] A communication plan exists to share the RACI with all involved parties - [ ] Decision map covers the top 5–10 highest-stakes decisions in the project +## Anti-Patterns + +- [ ] Do not assign more than one Accountable per task — shared accountability means no accountability +- [ ] Do not create a RACI with more than 5–6 roles — it becomes unreadable and unenforceable +- [ ] Do not include tasks so broad that the RACI cannot be acted upon — break down to decision-level granularity +- [ ] Do not skip the conflict resolution process — RACI matrices without a process for disputes are unused after the first disagreement +- [ ] Do not confuse Responsible with Accountable — document the distinction clearly for each role + ## Example Trigger Phrases - "Build a RACI matrix for our product launch" diff --git a/plugins/pm-operations/skills/risk-register/SKILL.md b/plugins/pm-operations/skills/risk-register/SKILL.md index 4e77618..ba16452 100644 --- a/plugins/pm-operations/skills/risk-register/SKILL.md +++ b/plugins/pm-operations/skills/risk-register/SKILL.md @@ -209,3 +209,11 @@ A risk is closed when: - "What risks should I document for a data migration project?" - "Generate a risk register for our steering committee" - "Help me identify and score risks for our Q3 delivery plan" + +## Anti-Patterns + +- [ ] Do not assign risks to "the team" or "TBD" — every risk must have a named individual owner +- [ ] Do not write mitigations as "monitor and review" — mitigations must describe what is actively being done to reduce likelihood or impact +- [ ] Do not delete closed risks — they provide an audit trail; archive them instead +- [ ] Do not confuse risks with issues — a risk is something that might happen; an issue is something that has already happened +- [ ] Do not leave Critical or High risks without a contingency plan — what happens if the mitigation fails must be documented diff --git a/plugins/pm-operations/skills/sop-writer/SKILL.md b/plugins/pm-operations/skills/sop-writer/SKILL.md index 680cf1f..8d0610a 100644 --- a/plugins/pm-operations/skills/sop-writer/SKILL.md +++ b/plugins/pm-operations/skills/sop-writer/SKILL.md @@ -92,3 +92,11 @@ NOTE: Steps must be written in imperative form. Each step must have one action o - "Write an SOP for [process]" - "Create a standard operating procedure for [task]" - "Write a work instruction for [process]" + +## Anti-Patterns + +- [ ] Do not write steps that contain more than one action — each step must be a single, auditable action in imperative form +- [ ] Do not omit a role from any step — every action must be assigned to a specific role or the SOP cannot be enforced +- [ ] Do not skip the non-conformance section — an SOP without a deviation process cannot meet audit or regulatory requirements +- [ ] Do not produce an SOP without a review date and version history — undated documents cannot be relied upon for compliance +- [ ] Do not use passive voice in procedure steps — write "Open the system" not "The system should be opened" diff --git a/plugins/pm-operations/skills/vendor-evaluation/SKILL.md b/plugins/pm-operations/skills/vendor-evaluation/SKILL.md index 0b30098..0543e2e 100644 --- a/plugins/pm-operations/skills/vendor-evaluation/SKILL.md +++ b/plugins/pm-operations/skills/vendor-evaluation/SKILL.md @@ -73,6 +73,14 @@ Security: ISO 27001 / SOC 2 certified? Where is data stored? Breach notification - [ ] Runner-up rationale explains why they lost (enables future conversations) - [ ] Contract terms to negotiate are specified +## Anti-Patterns + +- [ ] Do not weight all evaluation criteria equally — the scorecard must reflect the relative importance of each criterion +- [ ] Do not evaluate vendors only on features — security, support, contract terms, and financial stability matter too +- [ ] Do not produce a recommendation without explaining why the runner-up lost — this enables future vendor conversations +- [ ] Do not skip contract terms to negotiate — identifying leverage points is part of the procurement decision +- [ ] Do not recommend a vendor without stating the conditions under which the recommendation would change + ## Example Trigger Phrases - "Help me evaluate vendors for [procurement]" - "Create a vendor scorecard for [software/service]" diff --git a/plugins/pm-operations/skills/workshop-facilitation-guide/SKILL.md b/plugins/pm-operations/skills/workshop-facilitation-guide/SKILL.md index b94e584..f906056 100644 --- a/plugins/pm-operations/skills/workshop-facilitation-guide/SKILL.md +++ b/plugins/pm-operations/skills/workshop-facilitation-guide/SKILL.md @@ -140,6 +140,14 @@ End every session with: - [ ] Parking lot is used actively (not a graveyard) - [ ] Close captures decisions and actions before the room empties +## Anti-Patterns + +- [ ] Do not design a workshop without explicitly linking every activity to a session goal — purposeless activities waste participant time +- [ ] Do not schedule more than 90 minutes of continuous structured activity without a break +- [ ] Do not close a workshop without capturing decisions and actions before the room empties — post-session follow-up is too late +- [ ] Do not plan a workshop without considering psychological safety for sensitive topics — establish ground rules at the start +- [ ] Do not underestimate timing — add 20% buffer to all activity estimates, especially for groups over 8 people + ## Example Trigger Phrases - "Design a workshop for [goal] with [group]" diff --git a/plugins/pm-people/skills/360-feedback-template/SKILL.md b/plugins/pm-people/skills/360-feedback-template/SKILL.md index b5393c2..6abe6c9 100644 --- a/plugins/pm-people/skills/360-feedback-template/SKILL.md +++ b/plugins/pm-people/skills/360-feedback-template/SKILL.md @@ -247,6 +247,14 @@ Ask the user which output they need, then gather inputs: - [ ] Suggested actions are specific enough that the reviewee knows exactly what to do differently on Monday - [ ] Direct quotes are genuinely direct — not paraphrased into blandness +## Anti-Patterns + +- [ ] Do not write survey questions that ask about personality traits rather than observable behaviours ("is a good communicator" vs "communicates updates before deadlines") +- [ ] Do not write development feedback that names the person's character flaws instead of specific behaviours and their impact +- [ ] Do not aggregate ratings without noting high-variance scores — a 2/5 and a 5/5 averaged to 3.5 hides a real signal +- [ ] Do not include direct quotes in the report that could identify the reviewer in small teams — paraphrase or omit +- [ ] Do not write suggested actions so vague they could apply to anyone ("be more strategic") — every suggestion must name a specific observable behaviour change + ## Example Trigger Phrases - "Build a 360 feedback survey for a [role] at senior level" diff --git a/plugins/pm-people/skills/hiring-rubric/SKILL.md b/plugins/pm-people/skills/hiring-rubric/SKILL.md index 711b039..d9b7fe7 100644 --- a/plugins/pm-people/skills/hiring-rubric/SKILL.md +++ b/plugins/pm-people/skills/hiring-rubric/SKILL.md @@ -119,6 +119,14 @@ Suggest how to divide competencies across interview rounds to avoid repetition: - [ ] Red flags are specific to this role and level - [ ] Panel guide avoids competency overlap between rounds +## Anti-Patterns + +- [ ] Do not include competencies that overlap significantly — each dimension must assess a distinct quality +- [ ] Do not write behavioural questions that can be answered with a yes/no — use "Tell me about a time..." format +- [ ] Do not set a scoring bar without calibration guidance — "above bar" means nothing without concrete examples at each level +- [ ] Do not create a rubric with more than 6 competencies — panel interviews cannot reliably assess more +- [ ] Do not omit a "must-have vs. nice-to-have" distinction in the requirements — all criteria cannot carry equal weight + ## Example Trigger Phrases - "Create a hiring rubric for a [role]" diff --git a/plugins/pm-people/skills/performance-review/SKILL.md b/plugins/pm-people/skills/performance-review/SKILL.md index 7544990..5f6163b 100644 --- a/plugins/pm-people/skills/performance-review/SKILL.md +++ b/plugins/pm-people/skills/performance-review/SKILL.md @@ -108,6 +108,14 @@ Ask the user for these if not provided: - [ ] No vague phrases without evidence - [ ] Tone is professional and fair throughout +## Anti-Patterns + +- [ ] Do not inflate positive language to avoid difficult feedback — growth areas must be clearly stated, not buried +- [ ] Do not include feedback that isn't supported by specific examples — every development point needs evidence +- [ ] Do not write a review that only covers what happened in the last month — the full review period must be considered +- [ ] Do not omit development goals — a review without forward-looking guidance is incomplete +- [ ] Do not use language that could be read as discriminatory — avoid references to personality traits unrelated to work performance + ## Example Trigger Phrases - "Write a performance review for [name] based on these notes: [paste notes]" diff --git a/plugins/pm-people/skills/team-health-check/SKILL.md b/plugins/pm-people/skills/team-health-check/SKILL.md index 74cf5e6..c7f60ac 100644 --- a/plugins/pm-people/skills/team-health-check/SKILL.md +++ b/plugins/pm-people/skills/team-health-check/SKILL.md @@ -1,6 +1,6 @@ --- name: team-health-check -description: "Run a structured team health assessment. Use when asked to run a team health check, assess team morale, facilitate a team retrospective on ways of working, or evaluate team dynamics. Produces a health assessment across key dimensions with RAG status, underlying signals, and prioritised improvement actions." +description: "Runs a structured team health assessment across key dimensions. Use when asked to run a team health check, assess team morale, facilitate a retrospective on ways of working, or evaluate team dynamics. Produces a health assessment with RAG status per dimension, underlying signals, and prioritised improvement actions with named owners." --- # Team Health Check Skill @@ -253,6 +253,14 @@ Use this template to document results after the session or survey. - [ ] Results are shared with the team, not kept by management - [ ] Trend data is tracked across cycles to show improvement or regression +## Anti-Patterns + +- [ ] Do not run a health check without first establishing psychological safety — without it, scores reflect fear, not reality +- [ ] Do not treat a single health check as a trend — one data point cannot show improvement or regression +- [ ] Do not keep results with management without sharing them with the team — transparency is a prerequisite for trust +- [ ] Do not generate action items that are vague commitments like "improve communication" — every action must be specific and verifiable +- [ ] Do not assign actions to "the team" — each improvement action needs a single named owner + ## Example Trigger Phrases - "Run a team health check for my engineering squad" diff --git a/plugins/pm-people/skills/team-offsite-planner/SKILL.md b/plugins/pm-people/skills/team-offsite-planner/SKILL.md index eb92b6a..abf6f35 100644 --- a/plugins/pm-people/skills/team-offsite-planner/SKILL.md +++ b/plugins/pm-people/skills/team-offsite-planner/SKILL.md @@ -136,6 +136,14 @@ Template for the summary document to send within 48 hours: - [ ] Each working session has a stated output - [ ] Agenda has social/informal time built in +## Anti-Patterns + +- [ ] Do not fill the entire agenda with structured sessions — unstructured social time is essential for team bonding and must be built in +- [ ] Do not schedule more than 90 minutes of intensive working sessions without a break +- [ ] Do not design an offsite without clearly linking each session to the stated goals — purpose must be explicit +- [ ] Do not neglect logistics — venue, travel, dietary requirements, and accessibility must be confirmed before the agenda is finalised +- [ ] Do not plan without an energy management arc — high-energy collaboration sessions should not appear directly after lunch + ## Example Trigger Phrases - "Plan a 1-day offsite for my team of [size]" diff --git a/plugins/pm-planning/skills/feature-prioritisation/SKILL.md b/plugins/pm-planning/skills/feature-prioritisation/SKILL.md index 5912162..f5b6c2d 100644 --- a/plugins/pm-planning/skills/feature-prioritisation/SKILL.md +++ b/plugins/pm-planning/skills/feature-prioritisation/SKILL.md @@ -118,3 +118,11 @@ Recommend building: all Basic features first → Performance features for key us - [ ] Assumptions used in scoring are documented - [ ] Stakeholder politics or personal preferences are separated from framework score - [ ] Prioritisation is anchored to a specific scope (sprint / quarter / launch) + +## Anti-Patterns + +- [ ] Do not score items against different goals — every item in a prioritisation session must be scored against the same objective +- [ ] Do not omit deprioritised items — explicitly listing what was cut and why is as important as the ranked list +- [ ] Do not let stakeholder politics override framework scores without documenting the override and reason +- [ ] Do not mix RICE, ICE, or MoSCoW scores across frameworks in a single session — pick one framework per prioritisation exercise +- [ ] Do not treat the output as final without documenting the assumptions used in scoring — assumptions change, and the list must be revisitable diff --git a/plugins/pm-planning/skills/okr-builder/SKILL.md b/plugins/pm-planning/skills/okr-builder/SKILL.md index 726f813..cc89a83 100644 --- a/plugins/pm-planning/skills/okr-builder/SKILL.md +++ b/plugins/pm-planning/skills/okr-builder/SKILL.md @@ -84,3 +84,11 @@ Ask the user for these if not provided: - [ ] Maximum 4 KRs per objective - [ ] OKRs connect to the company or product North Star - [ ] Ambitious enough that 0.7 attainment is the expected score + +## Anti-Patterns + +- [ ] Do not accept output-based key results — any KR phrased as "launch X" or "complete Y" must be rewritten as an outcome with a baseline and target +- [ ] Do not write OKRs without asking for the company or product North Star — OKRs disconnected from the strategic context are just a goal-setting exercise +- [ ] Do not write more than 4 KRs per objective — too many KRs dilute focus and make scoring ambiguous at quarter end +- [ ] Do not use binary KRs (ship/don't ship) — every KR must be scorable on a 0.0–1.0 scale based on degree of achievement +- [ ] Do not skip the health check section on baselines — OKRs without current baselines cannot be scored objectively at quarter end diff --git a/plugins/pm-planning/skills/pricing-strategy/SKILL.md b/plugins/pm-planning/skills/pricing-strategy/SKILL.md index a1783d0..7d2f3bd 100644 --- a/plugins/pm-planning/skills/pricing-strategy/SKILL.md +++ b/plugins/pm-planning/skills/pricing-strategy/SKILL.md @@ -129,6 +129,14 @@ Ask the user for these if not provided: - [ ] Counter-metrics are defined to catch perverse incentives - [ ] Risks have specific mitigations (not just listed) +## Anti-Patterns + +- [ ] Do not base pricing solely on cost-plus — pricing must reflect value delivered to the customer +- [ ] Do not design tiers where the middle tier is clearly worse value — it undermines trust and pushes customers to extremes +- [ ] Do not change pricing without a migration plan for existing customers — surprise price changes cause churn +- [ ] Do not set enterprise pricing as "contact us" without a floor — it deters self-serve evaluation and qualification +- [ ] Do not skip competitive positioning — pricing in isolation from the market is incomplete strategy + ## Guidelines - Never price based on cost — price based on value delivered to the customer diff --git a/plugins/pm-planning/skills/rice-impact-matrix/SKILL.md b/plugins/pm-planning/skills/rice-impact-matrix/SKILL.md index 2768dfe..651beb6 100644 --- a/plugins/pm-planning/skills/rice-impact-matrix/SKILL.md +++ b/plugins/pm-planning/skills/rice-impact-matrix/SKILL.md @@ -1,6 +1,6 @@ --- name: rice-impact-matrix -description: "Score features using RICE and plot against strategic alignment for nuanced prioritisation. Use when asked to prioritise features, build a priority matrix, combine quantitative scoring with strategic fit, or decide what to build next with multiple competing initiatives. Produces a scored priority matrix with RICE scores, strategic alignment ratings, quadrant placement, and sequencing recommendations." +description: "Scores features using both RICE and strategic alignment for nuanced prioritisation. Use when asked to prioritise features, build a priority matrix, combine quantitative scoring with strategic fit, or decide what to build next with multiple competing initiatives. Produces a scored priority matrix with RICE scores, strategic alignment ratings, quadrant placement, and sequencing recommendations." --- # RICE + Strategic Alignment Skill @@ -60,3 +60,11 @@ Combined Score = RICE Score + (Strategic Alignment × 10) - [ ] Conflicts between RICE rank and strategic alignment are explicitly flagged - [ ] "Drop" recommendations are specific — not just "low priority, deprioritise" - [ ] Confidence levels on estimates are noted where weak (drives the 50% confidence flag) + +## Anti-Patterns + +- [ ] Do not treat the combined score as a definitive ranking — use it to structure a conversation, not replace one +- [ ] Do not rate strategic alignment as "high" because an initiative feels important without mapping it to a specific OKR +- [ ] Do not place all initiatives in the "Now" quadrant — a matrix with no "Drop" recommendations is not credible +- [ ] Do not ignore the conflict flag when RICE rank and strategic alignment sharply diverge +- [ ] Do not accept 100% confidence on estimates that have not been validated with data diff --git a/plugins/pm-planning/skills/rice-prioritisation/SKILL.md b/plugins/pm-planning/skills/rice-prioritisation/SKILL.md index 31228de..965748c 100644 --- a/plugins/pm-planning/skills/rice-prioritisation/SKILL.md +++ b/plugins/pm-planning/skills/rice-prioritisation/SKILL.md @@ -1,6 +1,6 @@ --- name: rice-prioritisation -description: "Score and rank product initiatives using the RICE framework. Use when asked to prioritise features, rank a backlog using RICE, score initiatives for quarterly planning, or apply an objective framework to a list of competing ideas. Produces a ranked RICE table with scores, quick wins and moonshot flags, dependency notes, and a recommended sequencing order." +description: "Scores and ranks product initiatives using the RICE framework. Use when asked to prioritise features, rank a backlog using RICE, score initiatives for quarterly planning, or apply an objective framework to a list of competing ideas. Produces a ranked RICE table with scores, quick wins and moonshot flags, dependency notes, and a recommended sequencing order." --- # RICE Prioritisation Skill @@ -57,3 +57,11 @@ RICE Score = (Reach × Impact × Confidence) / Effort - [ ] Quick wins and moonshots are explicitly called out - [ ] Dependencies that affect sequencing are noted - [ ] Any surprising ranking is investigated before accepting it + +## Anti-Patterns + +- [ ] Do not default to 100% confidence on estimates that lack supporting data — this inflates scores and misleads planning +- [ ] Do not treat RICE scores as a final decision — a ranking that surprises the team must be investigated before it is accepted +- [ ] Do not omit effort estimates from engineering — PM-only effort estimates are frequently optimistic and skew results +- [ ] Do not forget to note dependencies that would change the sequencing even if RICE scores suggest otherwise +- [ ] Do not score every initiative at the same impact level — if everything is "high impact," the framework produces no useful signal diff --git a/plugins/pm-planning/skills/roadmap-narrative/SKILL.md b/plugins/pm-planning/skills/roadmap-narrative/SKILL.md index 376ebb3..60e4f6c 100644 --- a/plugins/pm-planning/skills/roadmap-narrative/SKILL.md +++ b/plugins/pm-planning/skills/roadmap-narrative/SKILL.md @@ -54,3 +54,11 @@ Ask the user for these if not provided: - [ ] Progression narrative shows causal links between quarters (not just chronological listing) - [ ] "What's not on the roadmap" section includes at least 2 items with clear rationale - [ ] Language throughout is free of engineering jargon — tested by asking: "could a CFO repeat this?" + +## Anti-Patterns + +- [ ] Do not produce a list of features with dates and call it a narrative — every initiative must connect to a strategic theme +- [ ] Do not omit the "what's not on the roadmap" section — without it, the narrative lacks strategic discipline +- [ ] Do not write progression as a chronological list — show causal links between quarters (Q1 enables Q2 because…) +- [ ] Do not write the executive summary last and treat it as a summary — write it as the version stakeholders will repeat +- [ ] Do not let orphaned initiatives appear without a theme — either create a theme or flag the gap explicitly diff --git a/plugins/pm-planning/skills/roadmap-presentation/SKILL.md b/plugins/pm-planning/skills/roadmap-presentation/SKILL.md index aac7eff..5cf552c 100644 --- a/plugins/pm-planning/skills/roadmap-presentation/SKILL.md +++ b/plugins/pm-planning/skills/roadmap-presentation/SKILL.md @@ -128,3 +128,11 @@ Every roadmap needs a narrative, not just a timeline. Structure it as: - [ ] "What We're NOT Building" section has at least 2 items with rationale - [ ] Success metrics are specified per theme (not just a list of features) - [ ] Language is free of internal jargon — tested by asking: "could an external stakeholder understand this?" + +## Anti-Patterns + +- [ ] Do not put specific dates on NEXT or LATER items — use quarters or halves to signal appropriate confidence levels +- [ ] Do not show the same level of detail to executives and engineers — calibrate depth to audience or you lose both +- [ ] Do not omit the "What We're NOT Building" section — a roadmap without explicit deprioritisation becomes a wish list +- [ ] Do not present LATER items as commitments — frame everything outside NOW as directional, not promised +- [ ] Do not skip the success metrics section — without it, stakeholders cannot evaluate whether the roadmap is working diff --git a/plugins/pm-research/skills/clinical-case-summary/SKILL.md b/plugins/pm-research/skills/clinical-case-summary/SKILL.md index 9d13712..912e83b 100644 --- a/plugins/pm-research/skills/clinical-case-summary/SKILL.md +++ b/plugins/pm-research/skills/clinical-case-summary/SKILL.md @@ -71,10 +71,17 @@ WARNING: For documentation and educational purposes only. All clinical content m - Follow-up plan ## Quality Checks -- Patient details fully anonymised -- Allergies and medications included in handover formats -- Safety netting included in SOAP plan -- Disclaimer included +- [ ] Patient details fully anonymised +- [ ] Allergies and medications included in handover formats +- [ ] Safety netting included in SOAP plan +- [ ] Disclaimer included + +## Anti-Patterns + +- [ ] Do not include any identifiable patient information — full names, dates of birth, NHS or MRN numbers, or specific addresses must be anonymised or replaced with generic identifiers +- [ ] Do not omit the clinical disclaimer — this output is for documentation and educational purposes only and must not be presented as clinical advice +- [ ] Do not confuse the SBAR Recommendation with a treatment plan — R is what you need from the recipient, not a full management plan +- [ ] Do not list differential diagnoses without noting the reasoning for ranking — an unranked list of differentials is not clinically useful ## Example Trigger Phrases - "Write a clinical handover using SBAR for this patient" diff --git a/plugins/pm-research/skills/literature-review/SKILL.md b/plugins/pm-research/skills/literature-review/SKILL.md index a4dda9d..9464284 100644 --- a/plugins/pm-research/skills/literature-review/SKILL.md +++ b/plugins/pm-research/skills/literature-review/SKILL.md @@ -65,6 +65,14 @@ For each paper: internal validity, external validity, bias types, effect size si - [ ] Gaps identified — what the field still needs - [ ] All claims cited +## Anti-Patterns + +- [ ] Do not summarise papers one by one — evidence must be synthesised thematically across multiple studies, not presented as a sequence of abstracts +- [ ] Do not omit methodological critique — a literature review that only reports findings without assessing study quality is not a critical review +- [ ] Do not organise by chronology when thematic organisation is possible — chronological reviews bury the conceptual structure of the field +- [ ] Do not present contested findings as settled consensus — where evidence is mixed, name both sides and why the evidence diverges +- [ ] Do not skip the gap analysis — identifying what the field still needs is a core deliverable, not an optional addition + ## Example Trigger Phrases - "Write a literature review on [topic]" - "Synthesise the evidence on [topic] from these papers: [paste]" diff --git a/plugins/pm-research/skills/patient-communication/SKILL.md b/plugins/pm-research/skills/patient-communication/SKILL.md index 60dd1f5..c33319b 100644 --- a/plugins/pm-research/skills/patient-communication/SKILL.md +++ b/plugins/pm-research/skills/patient-communication/SKILL.md @@ -92,6 +92,14 @@ Yours sincerely, [Name, Title, Department] - [ ] No Latin or acronyms without explanation - [ ] Disclaimer that clinical review is required before sending +## Anti-Patterns + +- [ ] Do not use medical jargon without a plain-English explanation — write for the patient, not the clinician +- [ ] Do not omit a clear "next steps" section — patients must know exactly what to do after reading +- [ ] Do not produce final content without flagging that clinical review is required before sending +- [ ] Do not write above a Grade 8 reading level without a compelling reason — accessibility is the default +- [ ] Do not include Latin abbreviations (e.g. "p.r.n.", "b.d.") without spelling them out — they are not universally understood + ## Example Trigger Phrases - "Write a patient letter about [topic]" - "Create a patient information leaflet for [procedure]" diff --git a/plugins/pm-research/skills/research-protocol/SKILL.md b/plugins/pm-research/skills/research-protocol/SKILL.md index e7a1901..19d004f 100644 --- a/plugins/pm-research/skills/research-protocol/SKILL.md +++ b/plugins/pm-research/skills/research-protocol/SKILL.md @@ -92,6 +92,14 @@ Qualitative: [Framework — e.g. Braun & Clarke], [quality assurance] - [ ] Analysis plan is pre-specified (not "to be determined") - [ ] Timeline includes all phases from ethics approval to write-up +## Anti-Patterns + +- [ ] Do not write an analysis plan as "to be determined" — the analysis approach must be pre-specified before data collection +- [ ] Do not skip the ethical considerations section — all research involving human participants requires ethical review +- [ ] Do not define research questions so broadly that the study cannot answer them within scope and budget +- [ ] Do not conflate the research question with the hypothesis — state them separately and clearly +- [ ] Do not omit sample size justification — an underpowered study wastes resources and produces inconclusive results + ## Example Trigger Phrases - "Write a research protocol for [study]" - "Help me design a study to investigate [question]" diff --git a/plugins/pm-rituals/skills/pm-weekly-review/SKILL.md b/plugins/pm-rituals/skills/pm-weekly-review/SKILL.md index 452eaa7..42f58d4 100644 --- a/plugins/pm-rituals/skills/pm-weekly-review/SKILL.md +++ b/plugins/pm-rituals/skills/pm-weekly-review/SKILL.md @@ -115,6 +115,14 @@ Ask the user for these if not provided: - [ ] Total length is under 400 words (skimmable in 3 minutes) - [ ] Reflection section is honest, not aspirational +## Anti-Patterns + +- [ ] Do not report metrics without comparing to target or the prior week — absolute numbers without context are not useful +- [ ] Do not list blockers without a named owner and proposed resolution — unowned blockers stay blocked +- [ ] Do not write a weekly review that is longer than one page — it must be scannable in under 2 minutes +- [ ] Do not include more than 3 priorities for next week — a list of 8 "top priorities" means nothing is prioritised +- [ ] Do not skip the insights section — observations that inform future decisions are a PM's key value add + ## Guidelines - Keep the whole document under 400 words — if stakeholders won't read it, it doesn't exist diff --git a/plugins/pm-sales/skills/account-plan/SKILL.md b/plugins/pm-sales/skills/account-plan/SKILL.md index 390ce00..7a5ec67 100644 --- a/plugins/pm-sales/skills/account-plan/SKILL.md +++ b/plugins/pm-sales/skills/account-plan/SKILL.md @@ -88,6 +88,13 @@ At end of [period]: - [Expansion opportunity] progressed to [stage] - Health score moved from [current] to [target] +## Anti-Patterns + +- [ ] Do not list only executive contacts in the relationship map — champions and day-to-day users are often more influential on renewal decisions +- [ ] Do not set growth opportunity estimates without a basis — even rough ARR values prevent the plan from being treated seriously +- [ ] Do not treat "no known risks" as acceptable — if no risks are identified, the plan hasn't been scrutinised honestly +- [ ] Do not write 90-day actions as vague aspirations ("strengthen the relationship") — each action must specify a call, meeting, or deliverable with a named owner + ## Quality Checks - [ ] Relationship map identifies decision-makers, influencers, and any relationship gaps diff --git a/plugins/pm-sales/skills/discovery-call-prep/SKILL.md b/plugins/pm-sales/skills/discovery-call-prep/SKILL.md index 6728d27..fec59fb 100644 --- a/plugins/pm-sales/skills/discovery-call-prep/SKILL.md +++ b/plugins/pm-sales/skills/discovery-call-prep/SKILL.md @@ -99,6 +99,14 @@ This call is NOT successful if we only pitched and got "sounds interesting, send - [ ] Success criteria define what "not successful" looks like (not just the ideal outcome) - [ ] A specific next step is proposed (not "let's stay in touch") +## Anti-Patterns + +- [ ] Do not write the call hypothesis after the call — hypotheses written post-hoc are rationalisations, not testable predictions +- [ ] Do not open with a product pitch before establishing the prospect's problem — leading with pitch signals you are not there to learn, which closes discovery conversations +- [ ] Do not use closed questions in the discovery phase ("Do you have this problem?") — they produce yes/no answers that confirm bias rather than reveal pain +- [ ] Do not skip the "not successful" definition in success criteria — a call that ends with "send me more info" feels like progress but is not a qualified next step +- [ ] Do not treat all prospect research equally — recent news (last 90 days) is more relevant to call context than static company facts from LinkedIn + ## Example Trigger Phrases - "Prepare me for a discovery call with [company/contact]" - "Build a call brief for my meeting with [name] at [company]" diff --git a/plugins/pm-sales/skills/partnership-proposal/SKILL.md b/plugins/pm-sales/skills/partnership-proposal/SKILL.md index ee4f717..17781cb 100644 --- a/plugins/pm-sales/skills/partnership-proposal/SKILL.md +++ b/plugins/pm-sales/skills/partnership-proposal/SKILL.md @@ -226,3 +226,11 @@ How we'll know the partnership is working: - "Create a reseller partnership proposal for [Company]" - "Build the business case for a strategic partnership with [Partner]" - "Structure a technology integration partnership proposal" + +## Anti-Patterns + +- [ ] Do not write the value proposition from your own perspective — the "For Partner" section must be written from the partner's point of view, in the language of their goals and their customers +- [ ] Do not leave commercial terms as structure without numbers — a proposal that says "revenue share" without stating the percentage is not a proposal, it is a conversation opener +- [ ] Do not omit the "What we're not proposing" section — leaving unstated assumptions creates misaligned expectations that derail negotiations later +- [ ] Do not set success metrics unilaterally — metrics that only your company controls or cares about will not earn partner commitment +- [ ] Do not write a go-to-market plan with "TBD" owners — every activity must have a named owner on at least one side before the proposal goes out diff --git a/plugins/pm-sales/skills/proposal-writer/SKILL.md b/plugins/pm-sales/skills/proposal-writer/SKILL.md index ce40ee8..f71e8ca 100644 --- a/plugins/pm-sales/skills/proposal-writer/SKILL.md +++ b/plugins/pm-sales/skills/proposal-writer/SKILL.md @@ -94,6 +94,14 @@ Writes commercial proposals that win business — structured around the prospect - [ ] Next steps include a specific date and named action - [ ] "Valid until" date is included to create urgency +## Anti-Patterns + +- [ ] Do not lead with the solution before establishing that the problem is understood — the proposal must demonstrate problem comprehension first +- [ ] Do not use vague investment language like "competitive pricing" — every proposal must state a specific price or range +- [ ] Do not omit a "not included" section — undefined scope leads to disputes after the proposal is accepted +- [ ] Do not forget a "valid until" date — proposals without expiry create awkward situations and stale pricing +- [ ] Do not list next steps without naming who is responsible for each and what the expected timeline is + ## Example Trigger Phrases - "Write a proposal for [prospect] to [solve their problem]" - "Draft a statement of work for [project]" diff --git a/plugins/pm-sales/skills/sales-battlecard/SKILL.md b/plugins/pm-sales/skills/sales-battlecard/SKILL.md index 3623051..4e59665 100644 --- a/plugins/pm-sales/skills/sales-battlecard/SKILL.md +++ b/plugins/pm-sales/skills/sales-battlecard/SKILL.md @@ -86,3 +86,11 @@ We lose when: [Honest scenario — e.g. primary driver is lowest upfront cost] - "Build a battlecard against [competitor]" - "Create a competitive cheat sheet for [competitor]" - "Write objection handling for [competitor] comparisons" + +## Anti-Patterns + +- [ ] Do not minimise or ignore genuine competitor strengths — sales reps who encounter them unprepared lose credibility +- [ ] Do not write differentiators without proof points — a claim without evidence is marketing, not a battlecard +- [ ] Do not make the battlecard exhaustive — it is a one-page cheat sheet, not a full competitive analysis +- [ ] Do not include a "When we lose" section that is dishonestly optimistic — honest loss scenarios build rep trust +- [ ] Do not skip the review date — an outdated battlecard with wrong information is worse than no battlecard diff --git a/plugins/pm-sales/skills/sales-forecasting-model/SKILL.md b/plugins/pm-sales/skills/sales-forecasting-model/SKILL.md index 4f28823..00b7b82 100644 --- a/plugins/pm-sales/skills/sales-forecasting-model/SKILL.md +++ b/plugins/pm-sales/skills/sales-forecasting-model/SKILL.md @@ -128,3 +128,11 @@ To hit £[target]: - "Create a pipeline model for [team/business]" - "Help me build a bottom-up revenue forecast" - "What is our forecast for Q[N] based on current pipeline?" + +## Anti-Patterns + +- [ ] Do not present a single forecast number without scenario analysis — a forecast without upside and downside cases hides risk +- [ ] Do not use 100% confidence on conversion rates that are not backed by historical data — flag them as assumptions +- [ ] Do not skip the activity sanity check — a forecast number that requires unreachable activity levels is not credible +- [ ] Do not use top-down quota as the only forecast method when pipeline data exists — bottom-up is more accurate and defensible +- [ ] Do not omit the coverage ratio — without it, stakeholders cannot assess whether the pipeline is sufficient to hit target diff --git a/plugins/pm-social/skills/community-management-playbook/SKILL.md b/plugins/pm-social/skills/community-management-playbook/SKILL.md index 89bfd56..a20f256 100644 --- a/plugins/pm-social/skills/community-management-playbook/SKILL.md +++ b/plugins/pm-social/skills/community-management-playbook/SKILL.md @@ -300,6 +300,14 @@ Track these weekly: - [ ] Community health metrics have targets, not just labels - [ ] Platform-specific nuances are covered for every active channel +## Anti-Patterns + +- [ ] Do not delete genuine customer complaints to silence negative feedback — deletion damages trust more than the original complaint and can escalate a minor issue to a viral one +- [ ] Do not respond to competitor comparison comments publicly — engaging publicly with competitive comparisons amplifies them; redirect to DMs or ignore +- [ ] Do not use the same template response for every complaint — copy-paste responses on visible complaints are noticed by other users and undermine brand authenticity +- [ ] Do not leave a crisis without pausing scheduled content — queued posts published during an active brand crisis appear tone-deaf and make the situation worse +- [ ] Do not set response time SLAs that cannot be met with the available team size — an SLA that is consistently missed is worse than no SLA + ## Example Trigger Phrases - "Build a community management playbook for [brand]" diff --git a/plugins/pm-social/skills/influencer-brief/SKILL.md b/plugins/pm-social/skills/influencer-brief/SKILL.md index a84a770..71f789d 100644 --- a/plugins/pm-social/skills/influencer-brief/SKILL.md +++ b/plugins/pm-social/skills/influencer-brief/SKILL.md @@ -233,6 +233,14 @@ How we'll measure success: - [ ] Disclosure requirements are clearly stated (FTC / ASA compliance) - [ ] Important dates include a buffer for revisions +## Anti-Patterns + +- [ ] Do not leave creative guidelines so restrictive that the influencer's authentic voice is lost — prescriptiveness kills performance +- [ ] Do not omit the approval process — undefined approval workflows cause delays and missed publishing windows +- [ ] Do not set performance metrics that the influencer cannot influence — views are a metric, algorithm reach is not +- [ ] Do not skip the disclosure requirements section — FTC/ASA compliance is mandatory, not optional +- [ ] Do not list deliverables without specifying format, dimensions, and platform specs + ## Example Trigger Phrases - "Write an influencer brief for our product launch" diff --git a/plugins/pm-social/skills/social-ad-campaign/SKILL.md b/plugins/pm-social/skills/social-ad-campaign/SKILL.md index e94f642..ca2b406 100644 --- a/plugins/pm-social/skills/social-ad-campaign/SKILL.md +++ b/plugins/pm-social/skills/social-ad-campaign/SKILL.md @@ -326,3 +326,11 @@ Run structured tests — change one variable at a time: - "Create a LinkedIn ad campaign for [B2B SaaS product]" - "Write TikTok ad copy for [consumer brand]" - "Structure a paid social funnel for [offer]" + +## Anti-Patterns + +- [ ] Do not combine multiple campaign objectives in one campaign — pick one measurable goal or the algorithm cannot optimise correctly +- [ ] Do not skip retargeting suppression — existing customers receiving acquisition ads wastes budget and damages brand perception +- [ ] Do not launch without completing the tracking setup checklist — campaigns without verified pixel firing cannot be optimised or attributed +- [ ] Do not run A/B tests changing more than one variable at a time — multi-variable tests produce uninterpretable results +- [ ] Do not allocate equal budget across TOFU, MOFU, and BOFU — BOFU audiences convert at higher rates and deserve proportionally more budget per conversion diff --git a/plugins/pm-social/skills/social-media-audit/SKILL.md b/plugins/pm-social/skills/social-media-audit/SKILL.md index c7458ff..bf9d9b7 100644 --- a/plugins/pm-social/skills/social-media-audit/SKILL.md +++ b/plugins/pm-social/skills/social-media-audit/SKILL.md @@ -225,3 +225,11 @@ The fastest way to improve the score by 10+ points: - "How are we doing on social compared to competitors?" - "What's working and what isn't on our social channels?" - "Give me a social media health check for [brand]" + +## Anti-Patterns + +- [ ] Do not score platforms against guesswork — every score must be based on actual metrics provided or observable data +- [ ] Do not write recommendations as "post more content" or "improve engagement" — every action must be specific and measurable +- [ ] Do not use competitor benchmarks that are not based on real data — fabricated benchmarks invalidate the competitive gap analysis +- [ ] Do not audit content mix based on what should have been posted — analyse what was actually posted during the audit period +- [ ] Do not sequence the action plan by effort alone — sequence by impact × effort so the highest-value actions come first diff --git a/plugins/pm-social/skills/viral-content-framework/SKILL.md b/plugins/pm-social/skills/viral-content-framework/SKILL.md index ecf00b2..10fce0a 100644 --- a/plugins/pm-social/skills/viral-content-framework/SKILL.md +++ b/plugins/pm-social/skills/viral-content-framework/SKILL.md @@ -388,6 +388,14 @@ Apply the hook formulas and content structures from above to these topic angles: - [ ] Testing system is set up — 48-hour signal tracked for every post - [ ] CTA asks for a specific action, not a generic "like and share" +## Anti-Patterns + +- [ ] Do not create a single generic framework — hook formulas and content structures must be platform-specific +- [ ] Do not confuse reach with virality — high reach alone is not viral; content must drive sharing, saves, or resharing +- [ ] Do not produce hook formulas without testing guidance — frameworks without a testing system produce one-off results +- [ ] Do not ignore the shareability trigger — all content must have a clear reason why someone would send it to another person +- [ ] Do not design hooks that work only once — the framework must be repeatable, not a collection of one-time tactics + ## Example Trigger Phrases - "Build a viral content framework for [brand / creator]" diff --git a/plugins/pm-strategy/skills/ambiguity-resolver/SKILL.md b/plugins/pm-strategy/skills/ambiguity-resolver/SKILL.md index d41ada8..4ed012e 100644 --- a/plugins/pm-strategy/skills/ambiguity-resolver/SKILL.md +++ b/plugins/pm-strategy/skills/ambiguity-resolver/SKILL.md @@ -72,6 +72,13 @@ Input: *"We need to figure out what to do about our enterprise customers."* **In scope:** Enterprise accounts ($50K+ ARR) showing declining health scores in the last two quarters **Out of scope:** SMB segment, new enterprise acquisition strategy +## Anti-Patterns + +- [ ] Do not reframe the brief into questions that are still too broad to research — each reframed question must be answerable by a specific activity +- [ ] Do not list a research activity without stating what it would tell you and what it would NOT tell you +- [ ] Do not leave the decision owner as "leadership" or "the team" — name a specific person or role +- [ ] Do not omit an explicit out-of-scope boundary — without it, scope will expand organically and the brief becomes meaningless + ## Quality Checks - [ ] Every reframed question is specific enough to research (not "how do we improve things?") diff --git a/plugins/pm-strategy/skills/competitive-intelligence-monitor/SKILL.md b/plugins/pm-strategy/skills/competitive-intelligence-monitor/SKILL.md index b10e62a..0194b5d 100644 --- a/plugins/pm-strategy/skills/competitive-intelligence-monitor/SKILL.md +++ b/plugins/pm-strategy/skills/competitive-intelligence-monitor/SKILL.md @@ -56,6 +56,13 @@ Ask the user for these if not provided: **This Week's Strategic Summary:** [2 sentences max — what is the overall competitive landscape doing?] +## Anti-Patterns + +- [ ] Do not mark a signal as Low priority simply because it is new and unfamiliar — unknown competitive moves often deserve investigation before dismissal +- [ ] Do not provide "monitor" as the recommended response for a High-priority signal — High signals require a specific action with a named owner +- [ ] Do not include signals from competitors that are not relevant to the stated roadmap or strategic priorities — noise reduces the brief's usefulness and trains the team to ignore it +- [ ] Do not produce a diff-mode brief that is longer than the full report — if the diff output exceeds 300 words, it is a full report, not a diff + ## Quality Checks - [ ] Every High-priority signal has a specific response action and owner diff --git a/plugins/pm-strategy/skills/competitor-signal-tracker/SKILL.md b/plugins/pm-strategy/skills/competitor-signal-tracker/SKILL.md index de030a9..c50821b 100644 --- a/plugins/pm-strategy/skills/competitor-signal-tracker/SKILL.md +++ b/plugins/pm-strategy/skills/competitor-signal-tracker/SKILL.md @@ -1,6 +1,6 @@ --- name: competitor-signal-tracker -description: "Analyse competitor moves and surface strategic implications for your product. Use when asked to track competitor signals, analyse a competitor announcement, understand what a competitor is doing strategically, or produce a competitive intelligence report. Produces a categorised signal analysis with threat ratings, roadmap implications, and recommended responses." +description: "Analyse competitor moves and translate them into strategic implications for your product roadmap. Use when a competitor announces a new feature, pricing change, partnership, or strategic shift, or when producing a periodic competitive intelligence report. Produces a categorised signal analysis with reactive-vs-proactive assessment, threat ratings, specific roadmap implications, and recommended responses with owners." --- # Competitor Signal Tracker Skill @@ -44,6 +44,13 @@ Ask the user for these if not provided: #### Strategic Summary [2-3 sentences on the overall competitive landscape shift this period] +## Anti-Patterns + +- [ ] Do not rate a signal as High threat without explaining the specific roadmap item or customer segment it threatens — unjustified threat ratings lose credibility over time +- [ ] Do not treat a hiring signal as definitive proof of a strategic bet — hiring signals require corroboration from product, messaging, or pricing signals before acting on them +- [ ] Do not conflate a competitor's announcement with a competitor's shipped capability — press releases and blog posts often describe aspirations, not production features +- [ ] Do not recommend "accelerate existing initiative" for every High signal — sometimes the right response is to differentiate harder in an adjacent area rather than race the competitor directly + ## Quality Checks - [ ] Every signal is categorised (not just described) diff --git a/plugins/pm-strategy/skills/executive-update/SKILL.md b/plugins/pm-strategy/skills/executive-update/SKILL.md index f44edfb..15251d9 100644 --- a/plugins/pm-strategy/skills/executive-update/SKILL.md +++ b/plugins/pm-strategy/skills/executive-update/SKILL.md @@ -58,3 +58,11 @@ Ask the user for these if not provided: - [ ] Every risk has a mitigation or watch action - [ ] Every decision needed has at least two options and a recommendation - [ ] Written for a CFO or CEO — no jargon, all outcomes + +## Anti-Patterns + +- [ ] Do not lead with context or background — executives read the headline first; bury the important thing below two sentences of setup and they will miss it +- [ ] Do not present metrics without a comparison point — a number without context (vs. target, vs. last period) cannot be interpreted and will prompt follow-up questions +- [ ] Do not soften or spin risks — executives rely on these updates to make resource and escalation decisions; sanitised risk sections destroy the update's utility +- [ ] Do not present a "Decisions Needed" item without a recommendation — asking an executive to decide without your view forces them to do the analytical work the PM should have done +- [ ] Do not exceed 250 words in the main body — length signals the author has not done the compression work; every word over 250 reduces the chance the update is read diff --git a/plugins/pm-strategy/skills/stakeholder-influence-mapper/SKILL.md b/plugins/pm-strategy/skills/stakeholder-influence-mapper/SKILL.md index d8ae045..1793382 100644 --- a/plugins/pm-strategy/skills/stakeholder-influence-mapper/SKILL.md +++ b/plugins/pm-strategy/skills/stakeholder-influence-mapper/SKILL.md @@ -58,3 +58,11 @@ Ask the user for these if not provided: - [ ] Each stakeholder's talking points lead with their concern, not your agenda - [ ] At least one "do not approach until X is aligned" flag is considered - [ ] The ask from each stakeholder is a single, specific thing (not a vague "support") + +## Anti-Patterns + +- [ ] Do not approach high-influence blockers before aligning their sponsors — approach order determines outcome +- [ ] Do not create talking points that lead with your agenda — always lead with the stakeholder's stated concern +- [ ] Do not treat every stakeholder as equally important — focus depth on the decision-makers and key influencers +- [ ] Do not omit the "do not approach until X is aligned" flags — sequencing mistakes can permanently close doors +- [ ] Do not build the map based only on org chart position — influence often lives outside formal authority diff --git a/plugins/pm-strategy/skills/strategic-narrative-generator/SKILL.md b/plugins/pm-strategy/skills/strategic-narrative-generator/SKILL.md index 85b6a13..7d282c8 100644 --- a/plugins/pm-strategy/skills/strategic-narrative-generator/SKILL.md +++ b/plugins/pm-strategy/skills/strategic-narrative-generator/SKILL.md @@ -67,3 +67,11 @@ Ask the user for these if not provided: - [ ] Each theme has a specific, measurable metric (not "improve engagement") - [ ] Progression story shows causal links between quarters, not just chronological listing - [ ] "Not on the roadmap" section includes at least 2 items with clear rationale + +## Anti-Patterns + +- [ ] Do not produce a narrative that lists initiatives chronologically without showing causal progression — the story must show why each phase enables the next +- [ ] Do not use abstract strategic language that cannot be repeated by a non-technical listener — test whether someone could explain it back without the document +- [ ] Do not omit the "what's not on the roadmap" section — what you are choosing not to do is as important as what you are doing +- [ ] Do not set themes without measurable metrics — a theme without a metric cannot be tracked or held to account +- [ ] Do not skip the hard questions section — preparing for objections in advance is the purpose of the narrative exercise diff --git a/plugins/pm-writers/skills/aeo-optimizer/SKILL.md b/plugins/pm-writers/skills/aeo-optimizer/SKILL.md index a749773..4204e55 100644 --- a/plugins/pm-writers/skills/aeo-optimizer/SKILL.md +++ b/plugins/pm-writers/skills/aeo-optimizer/SKILL.md @@ -352,6 +352,14 @@ Before marking this task complete, verify each item: --- +## Anti-Patterns + +- [ ] Do not place links inside answer capsules — links break AI extractability and will cause the capsule to be skipped or paraphrased +- [ ] Do not write capsules longer than 80 words — oversized capsules are less likely to be extracted cleanly by AI engines +- [ ] Do not rewrite the H1 title — it serves SEO purposes and should follow different rules from H2s +- [ ] Do not add hedging phrases ("it depends", "there are many factors") inside capsules — commit to a direct, extractable answer +- [ ] Do not fabricate trust signals — only surface and note signals that actually exist in the article; inventing statistics undermines credibility + ## Example Trigger Phrases - "AEO optimize this article" diff --git a/plugins/pm-writers/skills/instagram-post-downloader/SKILL.md b/plugins/pm-writers/skills/instagram-post-downloader/SKILL.md index 6ed5aa5..f6ff797 100644 --- a/plugins/pm-writers/skills/instagram-post-downloader/SKILL.md +++ b/plugins/pm-writers/skills/instagram-post-downloader/SKILL.md @@ -1,6 +1,6 @@ --- name: instagram-post-downloader -description: "Download Instagram posts — single images or full carousels — directly from a URL. Fetches high-resolution files from Instagram's CDN, saves them into a named folder, and stitches carousel slides into a single PDF. Supports batch downloading of multiple URLs at once. Use when asked to download, save, or archive an Instagram post, reel thumbnail, or carousel." +description: "Downloads and saves Instagram posts as high-resolution files. Use when asked to download, save, or archive an Instagram post, reel thumbnail, or carousel. Fetches images from Instagram's CDN, saves them into a named folder, and stitches carousel slides into a single PDF. Supports batch downloading of multiple URLs at once." --- # Instagram Post Downloader Skill @@ -634,6 +634,14 @@ Before marking the task complete, verify each item: --- +## Anti-Patterns + +- [ ] Do not attempt to download private posts or content behind a login wall — this skill is for public posts only +- [ ] Do not ignore 429 rate-limit responses — always implement a backoff wait before retrying +- [ ] Do not save all downloads to a single flat folder when processing multiple accounts — use named subfolders per source +- [ ] Do not skip PDF stitching for carousel posts — individual slides delivered without a combined PDF are incomplete output +- [ ] Do not proceed if Instagram returns a login wall — surface the limitation clearly rather than returning an error silently + ## Example Trigger Phrases - "Download this Instagram post for me: https://www.instagram.com/p/ABC123/" diff --git a/plugins/pm-writers/skills/notes-humanizer/SKILL.md b/plugins/pm-writers/skills/notes-humanizer/SKILL.md index c174acb..5276c4b 100644 --- a/plugins/pm-writers/skills/notes-humanizer/SKILL.md +++ b/plugins/pm-writers/skills/notes-humanizer/SKILL.md @@ -1,6 +1,6 @@ --- name: notes-humanizer -description: Strips AI writing patterns from text and rewrites it to sound genuinely human — not by softening it, but by removing statistical defaults and injecting the specific signals that human writers produce. +description: "Strips AI writing patterns from text and rewrites it to sound genuinely human by removing statistical defaults and injecting the specific signals that human writers produce. Use when a draft reads as AI-generated, over-polished, or rhythmically uniform — including blog posts, emails, LinkedIn posts, or any prose that needs to sound like a real person wrote it. Produces a pattern audit, side-by-side comparison, itemised change log, and clean rewritten output ready to paste." --- # Notes Humanizer @@ -153,6 +153,14 @@ Present the output in the four-section structure defined above. The change log m - [ ] The clean output section has no annotations or formatting artifacts — ready to paste - [ ] If the original was already clean, that was stated explicitly rather than changes invented +## Anti-Patterns + +- [ ] Do not remove all em dashes — only the ones functioning as parenthetical substitutes should be removed; genuine dramatic pauses are valid +- [ ] Do not invent problems to justify changes when the original is already clean — report what was found honestly, even if the answer is "this text is mostly fine" +- [ ] Do not add the aside or opinion generically — the injected human signals must connect to an actual claim or argument in the text, not float in as decoration +- [ ] Do not list changes by category in the change log — every individual change must be listed separately with the specific reason for that specific instance +- [ ] Do not apply humanisation changes that alter the factual claims or intended meaning of the original text — the skill rewrites style, not substance + --- ## Example Trigger Phrases diff --git a/plugins/pm-writers/skills/substack-notes-scraper/SKILL.md b/plugins/pm-writers/skills/substack-notes-scraper/SKILL.md index 971edba..f64df87 100644 --- a/plugins/pm-writers/skills/substack-notes-scraper/SKILL.md +++ b/plugins/pm-writers/skills/substack-notes-scraper/SKILL.md @@ -1,6 +1,6 @@ --- name: substack-notes-scraper -description: Scrapes a Substack Notes page and exports engagement data (likes, comments, restacks) to a formatted .xlsx file with conditional formatting and summary stats. +description: "Scrapes a Substack Notes page and exports engagement data to a formatted .xlsx file. Use when asked to download, analyse, or export Substack Notes performance data including likes, comments, and restacks. Produces a formatted spreadsheet with conditional formatting, summary stats, and per-note engagement metrics." --- # Substack Notes Scraper @@ -167,6 +167,14 @@ After generating the file, report: --- +## Anti-Patterns + +- [ ] Do not proceed without a valid Substack handle or profile URL — scraping without a specific target cannot be completed +- [ ] Do not ignore rate-limit responses from Substack — implement backoff and reduce request frequency before retrying +- [ ] Do not export data without conditional formatting and summary stats — raw data without visualisation is not the expected output +- [ ] Do not attempt to access private or subscriber-only notes — this skill is for public Notes content only +- [ ] Do not produce output without a clear date range filter — undated exports make trend analysis impossible + ## Example Trigger Phrases - "Scrape my Substack Notes and export to Excel — my handle is @handle, last 60 days" diff --git a/plugins/pm-writers/skills/thumbnail-creator/SKILL.md b/plugins/pm-writers/skills/thumbnail-creator/SKILL.md index 0e57647..bab5f40 100644 --- a/plugins/pm-writers/skills/thumbnail-creator/SKILL.md +++ b/plugins/pm-writers/skills/thumbnail-creator/SKILL.md @@ -587,6 +587,14 @@ Before marking the task complete, verify each item: --- +## Anti-Patterns + +- [ ] Do not generate thumbnails without incorporating brand colours and style specs when provided — off-brand outputs must be regenerated +- [ ] Do not skip the evaluation step — all candidates must be scored before being presented to the user +- [ ] Do not present only one thumbnail candidate — always generate multiple options for comparison +- [ ] Do not include the full image generation prompts in a separate document — they must be included in the evaluation report for iteration reference +- [ ] Do not claim a thumbnail is final without offering an iteration round + ## Example Trigger Phrases - "Create thumbnails for this article"