fix(skills): add Anti-Patterns sections, fix descriptions, quality checks, and required inputs

- Add Anti-Patterns section (3-5 binary checkboxes) to all modified skills - Fix Quality Checks to use binary checkbox format where needed - Rewrite descriptions to verb-when-produces format where needed - Add Required Inputs sections to skills missing them - Fix email-triage frontmatter YAML quoting https://claude.ai/code/session_01MuGKn3a3Gbqoe8uM5Lmuqt
2026-06-08 10:20:50 +00:00
parent 44f69a541f
commit 4ff88bdbb1
88 changed files with 740 additions and 33 deletions
@@ -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"
@@ -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")
@@ -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"
@@ -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
@@ -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"
@@ -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]"
@@ -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")
@@ -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?")
@@ -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"
@@ -301,6 +301,14 @@ builders and response parsers.
 - [ ] 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
+- [ ] Breaking-change table covers at minimum: field removal, field rename, type change, making optional field required, endpoint removal, enum expansion, and default value change
+- [ ] Deprecation timeline durations are filled in with concrete values, not left as abstract placeholders
+- [ ] All three communication artifacts are present: initial deprecation notice, 30-day warning, and migration guide template
 - [ ] Sunset response headers (`Deprecation`, `Sunset`, `Link`) use correct RFC date format and real URL structure
 - [ ] SDK versioning alignment table is present and ties SDK major versions explicitly to API major versions
 - [ ] Maximum simultaneous supported versions is stated with a concrete number
@@ -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]"
@@ -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)
@@ -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"
@@ -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]"
@@ -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
@@ -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]"
@@ -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"
@@ -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"
@@ -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)
@@ -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
@@ -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"
@@ -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"
@@ -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?"
@@ -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"
@@ -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]"
@@ -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
@@ -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
@@ -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)
@@ -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]"
@@ -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"
@@ -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
@@ -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
@@ -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
@@ -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]"
@@ -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
@@ -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"
@@ -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
@@ -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
@@ -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]"
@@ -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
@@ -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"
@@ -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]"
@@ -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".
@@ -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]"
@@ -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
@@ -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
@@ -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]"
@@ -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
@@ -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
@@ -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?"
@@ -1,6 +1,6 @@
 ---
 name: launch-readiness
-description: "Run a comprehensive pre-launch readiness assessment across all functions. Use when asked to assess launch readiness, run a pre-launch review, create a go/no-go recommendation, or check if a product or feature is ready to ship. Produces a function-by-function readiness status, blockers list, risk register, and an explicit Go / Conditional Go / No-Go recommendation."
+description: "Assesses pre-launch readiness across every function and produces an explicit Go / Conditional Go / No-Go recommendation. Use when preparing for any product or feature launch, running a pre-launch review, or determining whether a release is safe to ship. Produces a function-by-function readiness status, a ranked blockers list with owners and deadlines, a risk register, and a clearly reasoned launch recommendation."
 ---

 # Launch Readiness Skill
@@ -80,3 +80,11 @@ Ask the user for these if not provided:
 - [ ] Analytics events are verified in staging, not just implemented
 - [ ] Go/No-Go decision has a named decision-maker and a cut-off time
 - [ ] At least one post-launch monitoring check is scheduled (e.g., T+2hr, T+24hr)
+
+## Anti-Patterns
+
+- [ ] Do not mark a function as "Ready" without evidence — green status must be backed by a completed checklist item, not an assumption
+- [ ] Do not issue a Conditional Go without specifying exactly what conditions must be met and by when — vague conditions are not conditions
+- [ ] Do not treat the rollback plan as complete unless it has been tested in staging, not just documented
+- [ ] Do not assign blockers to "the team" — every blocker must have a single named owner or it will not be resolved before launch
+- [ ] Do not skip the analytics verification step — unverified tracking events mean the launch will be invisible and cannot be evaluated
@@ -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]"
@@ -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]"
@@ -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
@@ -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
@@ -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]"
@@ -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]"
@@ -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]"
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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"
@@ -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'"
@@ -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
@@ -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
@@ -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]"
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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"
@@ -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
@@ -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
@@ -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