fix(skills): add Anti-Patterns and fix descriptions for remaining skills (batch 2)

Processed 24 skills: pr-description-writer through tax-planning-checklist.
Added Anti-Patterns sections to all 24 skills.
Added Required Inputs section to product-launch-checklist.
Rewrote descriptions for retro-analysis, substack-notes-scraper, and sycophancy-challenger.

https://claude.ai/code/session_01MuGKn3a3Gbqoe8uM5Lmuqt

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]"

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

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]"

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

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]"

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

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

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]"

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]"

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]"

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

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"

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]"

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]"

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]"

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*

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

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

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

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

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"

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]"

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"

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]"