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
2026-06-08 13:06:21 +00:00
parent fb85a1cb55
commit affae033fe
171 changed files with 1428 additions and 56 deletions
@@ -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
@@ -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"
@@ -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]"
@@ -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

 ```
@@ -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
@@ -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