diff --git a/skills/content-calendar/SKILL.md b/skills/content-calendar/SKILL.md index 88d0452..f68f3d6 100644 --- a/skills/content-calendar/SKILL.md +++ b/skills/content-calendar/SKILL.md @@ -50,6 +50,14 @@ For each "High Priority" post, add one repurposing suggestion — e.g. "Turn thi - [ ] Formats match platform norms - [ ] Repurposing map covers all High Priority posts +## Anti-Patterns + +- [ ] Do not fill the calendar with generic topic placeholders — every entry must have a specific, usable topic and hook +- [ ] Do not stack the same pillar or format on consecutive days — variety is required +- [ ] Do not produce opening hooks that start with "Did you know" or other cliché openers +- [ ] Do not ignore channel norms — formats must match the platform (no long-form threads for Instagram) +- [ ] Do not skip the repurposing map for High Priority posts + ## Example Trigger Phrases - "Build me a 4-week content calendar for [brand]" diff --git a/skills/contract-review/SKILL.md b/skills/contract-review/SKILL.md index f83533e..7566700 100644 --- a/skills/contract-review/SKILL.md +++ b/skills/contract-review/SKILL.md @@ -65,6 +65,14 @@ WARNING: This review is for informational purposes only and does not constitute - [ ] Plain English summary can be understood by a non-lawyer - [ ] Disclaimer is included +## Anti-Patterns + +- [ ] Do not provide legal advice or suggest the review substitutes for qualified legal counsel +- [ ] Do not skip flagging unusual or one-sided clauses because they appear standard +- [ ] Do not omit a plain-English summary — legal jargon alone is not useful output +- [ ] Do not rate risk without explaining what specifically drives that rating +- [ ] Do not ignore missing clauses — absence of key protections is itself a risk + ## Example Trigger Phrases - "Review this contract: [paste]" - "Flag the key risks in this agreement" diff --git a/skills/cs-escalation-brief/SKILL.md b/skills/cs-escalation-brief/SKILL.md index 0cca77d..31a6690 100644 --- a/skills/cs-escalation-brief/SKILL.md +++ b/skills/cs-escalation-brief/SKILL.md @@ -174,3 +174,11 @@ Include: - [ ] ARR at risk is quantified - [ ] Communication plan has owners and dates — not "TBD" - [ ] Language is professional and blameless toward individuals + +## Anti-Patterns + +- [ ] Do not assign blame to individuals — focus on system failures and process gaps +- [ ] Do not downplay ARR at risk or describe churn risk vaguely without a number +- [ ] Do not leave resolution plan ownership as "TBD" or unassigned +- [ ] Do not write the brief without a clear ask from the escalation owner +- [ ] Do not omit the customer's own stated position — their perspective must be represented fairly diff --git a/skills/cs-health-scorecard/SKILL.md b/skills/cs-health-scorecard/SKILL.md index 17237b7..32a080e 100644 --- a/skills/cs-health-scorecard/SKILL.md +++ b/skills/cs-health-scorecard/SKILL.md @@ -139,3 +139,11 @@ Score each dimension 1–5. Weight as shown. Calculate weighted total out of 100 - [ ] Actions have owners and deadlines - [ ] Renewal probability is calibrated against pipeline reality - [ ] Trend arrows reflect direction of change vs. last scorecard, not just current state + +## Anti-Patterns + +- [ ] Do not score health dimensions on gut feel — every score needs specific supporting evidence +- [ ] Do not give a Green status to accounts with unresolved P1 issues or missed milestones +- [ ] Do not list risks vaguely — "low engagement" without specifics is not actionable +- [ ] Do not leave recommended actions without named owners and deadlines +- [ ] Do not conflate product usage frequency with product value delivery diff --git a/skills/customer-journey-map/SKILL.md b/skills/customer-journey-map/SKILL.md index 5106df3..7fda6b4 100644 --- a/skills/customer-journey-map/SKILL.md +++ b/skills/customer-journey-map/SKILL.md @@ -206,6 +206,14 @@ Low 😤 │ * * - [ ] Emotion curve shows the real experience — not an aspirationally positive version - [ ] Research gaps are documented — the map reflects what is known, not assumed +## Anti-Patterns + +- [ ] Do not build the map from assumptions alone — ground at least the pain points in real customer data or research +- [ ] Do not treat all journey stages as equally weighted — identify the highest-friction moments explicitly +- [ ] Do not omit the emotional layer — a journey map without emotions is a process flow, not a customer map +- [ ] Do not create generic touchpoints that apply to any product — each touchpoint must be specific to this product and customer +- [ ] Do not leave opportunities unranked — prioritise by impact and feasibility + ## Example Trigger Phrases - "Map the customer journey for [product]" diff --git a/skills/customer-success-plan/SKILL.md b/skills/customer-success-plan/SKILL.md index 55a966f..ef6e778 100644 --- a/skills/customer-success-plan/SKILL.md +++ b/skills/customer-success-plan/SKILL.md @@ -183,6 +183,14 @@ If the success plan falls off track: - [ ] Plan is written to be shared with the customer — no internal-only commentary in this document - [ ] Executive sponsor is identified and has an engagement role +## Anti-Patterns + +- [ ] Do not define success metrics that the vendor controls — metrics must reflect the customer's business outcomes +- [ ] Do not set milestone dates without customer confirmation — unilateral timelines undermine joint ownership +- [ ] Do not create a plan the customer hasn't agreed to — it must be mutual, not a CSM's internal plan +- [ ] Do not leave ownership fields blank or assigned to "CS team" — every action needs a named owner +- [ ] Do not confuse product adoption milestones with customer business outcomes — both are needed but are not the same + ## Example Trigger Phrases - "Build a success plan for [Account Name] who just signed" diff --git a/skills/dashboard-brief/SKILL.md b/skills/dashboard-brief/SKILL.md index 094972e..c8584bc 100644 --- a/skills/dashboard-brief/SKILL.md +++ b/skills/dashboard-brief/SKILL.md @@ -114,6 +114,14 @@ Flag any fields that may not exist in current data infrastructure. - [ ] Data requirements section flags any missing fields - [ ] Filters are practical and don't require IT to configure +## Anti-Patterns + +- [ ] Do not specify metrics that the available data sources cannot actually support — always validate data availability +- [ ] Do not include more than 8–10 primary metrics on a single dashboard — more creates noise, not insight +- [ ] Do not skip the primary business question — a dashboard without a north-star question becomes a vanity metrics display +- [ ] Do not choose chart types for aesthetic reasons — every chart type must match the data relationship it represents +- [ ] Do not leave filter configurations vague — specify exact filter values, not just filter categories + ## Example Trigger Phrases - "Design a dashboard to track [business process]" diff --git a/skills/data-analysis-standard/SKILL.md b/skills/data-analysis-standard/SKILL.md index 6f42515..9d054f3 100644 --- a/skills/data-analysis-standard/SKILL.md +++ b/skills/data-analysis-standard/SKILL.md @@ -117,6 +117,14 @@ Ask the user for these if not provided: - [ ] What the data cannot tell us is explicitly named - [ ] Recommended action includes an owner and timeline +## Anti-Patterns + +- [ ] Do not present correlations as causation — always state the distinction explicitly +- [ ] Do not report a metric movement without stating the time window and comparison baseline +- [ ] Do not skip the "so what" — raw observations without recommended actions are incomplete analysis +- [ ] Do not overstate confidence — label hypotheses clearly and note what data would be needed to confirm them +- [ ] Do not ignore segment breakdowns — aggregate metrics can mask opposing trends in sub-segments + ## Guidelines - Always state what the data *cannot* tell you — never oversell confidence diff --git a/skills/data-pipeline-spec/SKILL.md b/skills/data-pipeline-spec/SKILL.md index d1776bc..0bbb907 100644 --- a/skills/data-pipeline-spec/SKILL.md +++ b/skills/data-pipeline-spec/SKILL.md @@ -212,6 +212,14 @@ List each transformation in execution order. For ELT pipelines, this is the dbt - [ ] Failure modes include a documented recovery owner - [ ] PII fields are identified and a treatment plan is specified +## Anti-Patterns + +- [ ] Do not spec a pipeline without defining SLAs — "as fast as possible" is not an acceptable freshness target +- [ ] Do not omit error handling and dead-letter queue strategy — every pipeline must specify what happens to failed records +- [ ] Do not design idempotent loads without documenting the deduplication key — assume reruns will happen +- [ ] Do not leave data quality rules implicit — schema validation, null checks, and referential integrity must be explicit +- [ ] Do not ignore schema evolution — specify how upstream schema changes are detected and handled + ## Example Trigger Phrases - "Design a data pipeline for our Salesforce to Snowflake sync" diff --git a/skills/database-migration-plan/SKILL.md b/skills/database-migration-plan/SKILL.md index 582bba9..196d2e7 100644 --- a/skills/database-migration-plan/SKILL.md +++ b/skills/database-migration-plan/SKILL.md @@ -452,3 +452,11 @@ Follow this checklist on the day of migration. Mark each step as done before pro - [ ] Lock types are identified for every DDL statement — no "should be fine" assumptions - [ ] The deployment runbook names who runs each step, not just what to run - [ ] Phase 4 (contract) is explicitly gated on the rollback window passing — not run on the same day as Phase 3 + +## Anti-Patterns + +- [ ] Do not combine the expand and contract phases into a single deployment — they must be separated by a deployment cycle +- [ ] Do not run DDL changes without first testing on a production-sized data clone +- [ ] Do not skip the NOT VALID + VALIDATE pattern for constraint additions on large tables — it causes full table locks +- [ ] Do not define a rollback as "restore from backup" — each phase must have an explicit, fast rollback procedure +- [ ] Do not omit dual-write logic during the transition period — removing the old column before all writers are updated causes data loss diff --git a/skills/database-schema-design/SKILL.md b/skills/database-schema-design/SKILL.md index b10b10b..49df946 100644 --- a/skills/database-schema-design/SKILL.md +++ b/skills/database-schema-design/SKILL.md @@ -354,3 +354,11 @@ If this schema is being introduced to an existing system, note the migration app - [ ] JSONB columns are justified — not used as a substitute for proper schema design on queryable fields - [ ] Normalization decisions are documented with reasoning, not just stated - [ ] Migration notes address existing data if this is a schema change, not a greenfield schema + +## Anti-Patterns + +- [ ] Do not use JSONB columns as a substitute for proper relational schema design on fields that will be queried +- [ ] Do not add indexes speculatively — every index must be justified by a specific access pattern +- [ ] Do not omit timezone-awareness — use TIMESTAMPTZ, never plain TIMESTAMP +- [ ] Do not design without documenting normalization decisions — future maintainers need the reasoning, not just the structure +- [ ] Do not skip the access patterns section — schema without query patterns cannot be evaluated for correctness diff --git a/skills/financial-model-narrative/SKILL.md b/skills/financial-model-narrative/SKILL.md index a84b630..ad97276 100644 --- a/skills/financial-model-narrative/SKILL.md +++ b/skills/financial-model-narrative/SKILL.md @@ -63,6 +63,14 @@ For each significant variance: - [ ] Audience-appropriate language (board vs investor vs management) - [ ] One-off items clearly distinguished from recurring items +## Anti-Patterns + +- [ ] Do not list numbers without explaining what is driving them — narrative must go beyond restating the figures +- [ ] Do not mix one-off items with recurring performance without clearly distinguishing them +- [ ] Do not write the same level of detail for all line items — focus depth on the items that matter most +- [ ] Do not omit forward-looking commentary — a narrative without outlook is incomplete for board or investor audiences +- [ ] Do not use technical accounting language without translation — the audience is executives, not accountants + ## Example Trigger Phrases - "Write a financial narrative for these results: [paste numbers]" - "Turn this P&L into a board narrative" diff --git a/skills/go-to-market-planner/SKILL.md b/skills/go-to-market-planner/SKILL.md index 478d993..109ff8c 100644 --- a/skills/go-to-market-planner/SKILL.md +++ b/skills/go-to-market-planner/SKILL.md @@ -131,3 +131,11 @@ Ask the user for these if not provided: - [ ] Success metrics include a measurement window (30/60/90 days) - [ ] Rollback procedure is confirmed for Tier 1 and 2 launches - [ ] Post-launch retrospective is scheduled + +## Anti-Patterns + +- [ ] Do not build a Tier 1 GTM plan for an incremental feature update — tier the launch appropriately before planning +- [ ] Do not create activity lists without named owners and due dates — unowned tasks do not get done +- [ ] Do not skip the rollback procedure for Tier 1 and 2 launches — every significant launch must have an abort plan +- [ ] Do not treat marketing and engineering as separate tracks — cross-functional coordination is the whole point of a GTM plan +- [ ] Do not set success metrics without a defined measurement window — "increase signups" is not a measurable target diff --git a/skills/go-to-market/SKILL.md b/skills/go-to-market/SKILL.md index af6df9d..54131a2 100644 --- a/skills/go-to-market/SKILL.md +++ b/skills/go-to-market/SKILL.md @@ -89,6 +89,14 @@ Before delivering output, verify: - [ ] Use cases include a Before/After structure - [ ] Language is consistent with the target customer's vocabulary (not internal engineering terms) +## Anti-Patterns + +- [ ] Do not write feature descriptions instead of benefits — the GTM pack must translate features into customer value +- [ ] Do not use the same messaging across all buyer personas — each role has different priorities and language +- [ ] Do not create a positioning statement that could apply to any competitor — differentiation must be specific and defensible +- [ ] Do not skip the "not for" section — defining who this is not for sharpens positioning and prevents misdirected sales effort +- [ ] Do not list use cases without tying them to specific job titles or buyer roles + ## Example Trigger Phrases - "Create a positioning statement for [product]" diff --git a/skills/grant-proposal/SKILL.md b/skills/grant-proposal/SKILL.md index b4d4ead..6581169 100644 --- a/skills/grant-proposal/SKILL.md +++ b/skills/grant-proposal/SKILL.md @@ -96,6 +96,14 @@ Funder test: does this problem align with [funder] stated priorities? Make the c - [ ] Sustainability section explains what happens after the grant ends - [ ] Word limits respected +## Anti-Patterns + +- [ ] Do not write a generic proposal — every section must be tailored to the specific funder's stated priorities +- [ ] Do not exceed the specified word or page limits — over-length proposals are disqualified at many funders +- [ ] Do not leave the sustainability section vague — funders need to know what happens after grant funding ends +- [ ] Do not use jargon the funder's reviewers won't understand — write for the panel, not the project team +- [ ] Do not underspecify the budget narrative — every significant line item must be justified with method and reasoning + ## Example Trigger Phrases - "Write a grant proposal for [project] applying to [funder]" - "Help me write a funding application for [grant programme]" diff --git a/skills/hiring-rubric/SKILL.md b/skills/hiring-rubric/SKILL.md index 711b039..d9b7fe7 100644 --- a/skills/hiring-rubric/SKILL.md +++ b/skills/hiring-rubric/SKILL.md @@ -119,6 +119,14 @@ Suggest how to divide competencies across interview rounds to avoid repetition: - [ ] Red flags are specific to this role and level - [ ] Panel guide avoids competency overlap between rounds +## Anti-Patterns + +- [ ] Do not include competencies that overlap significantly — each dimension must assess a distinct quality +- [ ] Do not write behavioural questions that can be answered with a yes/no — use "Tell me about a time..." format +- [ ] Do not set a scoring bar without calibration guidance — "above bar" means nothing without concrete examples at each level +- [ ] Do not create a rubric with more than 6 competencies — panel interviews cannot reliably assess more +- [ ] Do not omit a "must-have vs. nice-to-have" distinction in the requirements — all criteria cannot carry equal weight + ## Example Trigger Phrases - "Create a hiring rubric for a [role]" diff --git a/skills/incident-postmortem/SKILL.md b/skills/incident-postmortem/SKILL.md index 1b060a6..7390bec 100644 --- a/skills/incident-postmortem/SKILL.md +++ b/skills/incident-postmortem/SKILL.md @@ -140,6 +140,14 @@ Rules for action items: - [ ] No action item contains vague language like "improve monitoring", "increase resilience", or "better testing" — each must name a specific change - [ ] Executive summary is readable by non-technical leadership +## Anti-Patterns + +- [ ] Do not assign blame to individuals — postmortems must focus on system and process failures +- [ ] Do not write action items with vague language like "improve monitoring" — each must name a specific, ownable change +- [ ] Do not skip the contributing factors — root cause alone misses the systemic issues that enable incidents +- [ ] Do not omit the detection timeline — how long it took to detect matters as much as how long it took to resolve +- [ ] Do not treat the postmortem as closed until all action items have named owners and due dates + ## Usage Examples - "Write a postmortem for the [incident name] outage" - "Help me write a P1 incident report" diff --git a/skills/influencer-brief/SKILL.md b/skills/influencer-brief/SKILL.md index a84a770..71f789d 100644 --- a/skills/influencer-brief/SKILL.md +++ b/skills/influencer-brief/SKILL.md @@ -233,6 +233,14 @@ How we'll measure success: - [ ] Disclosure requirements are clearly stated (FTC / ASA compliance) - [ ] Important dates include a buffer for revisions +## Anti-Patterns + +- [ ] Do not leave creative guidelines so restrictive that the influencer's authentic voice is lost — prescriptiveness kills performance +- [ ] Do not omit the approval process — undefined approval workflows cause delays and missed publishing windows +- [ ] Do not set performance metrics that the influencer cannot influence — views are a metric, algorithm reach is not +- [ ] Do not skip the disclosure requirements section — FTC/ASA compliance is mandatory, not optional +- [ ] Do not list deliverables without specifying format, dimensions, and platform specs + ## Example Trigger Phrases - "Write an influencer brief for our product launch" diff --git a/skills/infra-as-code-review/SKILL.md b/skills/infra-as-code-review/SKILL.md index 65c88f8..5b5f3e3 100644 --- a/skills/infra-as-code-review/SKILL.md +++ b/skills/infra-as-code-review/SKILL.md @@ -290,3 +290,11 @@ Medium and Low findings should be tracked as follow-up issues with a committed r - [ ] Code snippets in findings show both the problematic code AND the corrected version - [ ] Overall risk rating is justified by the highest-severity open finding - [ ] Checklist items are binary (checkable) — not narrative observations + +## Anti-Patterns + +- [ ] Do not mark a finding as Low if it involves hardcoded credentials or secrets in any form — always Critical +- [ ] Do not review IaC in isolation from the deployment context — networking and IAM must be evaluated together +- [ ] Do not produce narrative findings without the specific resource name, file, and line number +- [ ] Do not skip the "Required Actions Before Merge" summary — reviewers need a clear blocking list, not just a full report +- [ ] Do not approve code where encryption at rest or in transit is missing on data stores, even if not explicitly flagged by the requester diff --git a/skills/instagram-post-downloader/SKILL.md b/skills/instagram-post-downloader/SKILL.md index 6ed5aa5..f6ff797 100644 --- a/skills/instagram-post-downloader/SKILL.md +++ b/skills/instagram-post-downloader/SKILL.md @@ -1,6 +1,6 @@ --- name: instagram-post-downloader -description: "Download Instagram posts — single images or full carousels — directly from a URL. Fetches high-resolution files from Instagram's CDN, saves them into a named folder, and stitches carousel slides into a single PDF. Supports batch downloading of multiple URLs at once. Use when asked to download, save, or archive an Instagram post, reel thumbnail, or carousel." +description: "Downloads and saves Instagram posts as high-resolution files. Use when asked to download, save, or archive an Instagram post, reel thumbnail, or carousel. Fetches images from Instagram's CDN, saves them into a named folder, and stitches carousel slides into a single PDF. Supports batch downloading of multiple URLs at once." --- # Instagram Post Downloader Skill @@ -634,6 +634,14 @@ Before marking the task complete, verify each item: --- +## Anti-Patterns + +- [ ] Do not attempt to download private posts or content behind a login wall — this skill is for public posts only +- [ ] Do not ignore 429 rate-limit responses — always implement a backoff wait before retrying +- [ ] Do not save all downloads to a single flat folder when processing multiple accounts — use named subfolders per source +- [ ] Do not skip PDF stitching for carousel posts — individual slides delivered without a combined PDF are incomplete output +- [ ] Do not proceed if Instagram returns a login wall — surface the limitation clearly rather than returning an error silently + ## Example Trigger Phrases - "Download this Instagram post for me: https://www.instagram.com/p/ABC123/" diff --git a/skills/investor-pitch-deck/SKILL.md b/skills/investor-pitch-deck/SKILL.md index 677fcaa..83f53e8 100644 --- a/skills/investor-pitch-deck/SKILL.md +++ b/skills/investor-pitch-deck/SKILL.md @@ -51,6 +51,14 @@ For each slide: - [ ] Ask slide specifies use of funds and 18-month milestones - [ ] TAM is bottoms-up where possible +## Anti-Patterns + +- [ ] Do not include a "no real competitors" slide — every company has competition and investors will discount founders who claim otherwise +- [ ] Do not use a top-down TAM calculation without a bottoms-up validation — investors distrust pure top-down market sizing +- [ ] Do not leave the ask vague — specify the amount, use of funds, and 18-month milestones the funding enables +- [ ] Do not let traction slides show vanity metrics — focus on revenue, retention, and growth rate over downloads and signups +- [ ] Do not bury the problem slide — investors must understand and feel the pain before they care about the solution + ## Example Trigger Phrases - "Build a pitch deck structure for [company]" - "Help me structure my Series A deck" diff --git a/skills/investor-update/SKILL.md b/skills/investor-update/SKILL.md index 49e0348..8537f75 100644 --- a/skills/investor-update/SKILL.md +++ b/skills/investor-update/SKILL.md @@ -119,6 +119,14 @@ Hi [Investor names or "all"], - [ ] Total length is skimmable in 3–4 minutes - [ ] No spin or buzzwords +## Anti-Patterns + +- [ ] Do not omit challenges or bad news — sanitised updates erode investor trust faster than bad results do +- [ ] Do not bury the lead — use BLUF structure and put the most important news in the first paragraph +- [ ] Do not send an update without a clear "Ask" section — investors who want to help need to know how +- [ ] Do not use buzzwords or spin — investors see hundreds of updates and will see through vague positive language +- [ ] Do not report metrics without a comparison baseline — numbers without context (vs. last period or target) are meaningless + ## Example Trigger Phrases - "Write an investor update for [month/quarter]" diff --git a/skills/job-application/SKILL.md b/skills/job-application/SKILL.md index 8dd5d03..a2fbbb5 100644 --- a/skills/job-application/SKILL.md +++ b/skills/job-application/SKILL.md @@ -1,6 +1,6 @@ --- name: job-application -description: "Tailor a CV and cover letter to a specific job description. Use when asked to write a cover letter, tailor a CV or resume, optimise for ATS, match a job description, or prepare a job application. Produces an ATS-optimised tailored CV summary and a personalised cover letter." +description: "Tailors a CV and cover letter to a specific job description. Use when asked to write a cover letter, tailor a CV or resume, optimise for ATS, match a job description, or prepare a job application. Produces an ATS-optimised tailored CV summary and a personalised cover letter aligned to the role's requirements." --- # Job Application Skill @@ -120,6 +120,14 @@ Before submitting: - [ ] Cover letter is 250–350 words - [ ] Gaps are either addressed or strategically omitted +## Anti-Patterns + +- [ ] Do not fabricate or embellish experience — only use real achievements from the provided CV +- [ ] Do not use the same cover letter template for every role — every letter must reference specific details of the job description +- [ ] Do not address selection criteria that aren't in the JD — match keywords the employer actually used +- [ ] Do not omit ATS optimisation — ensure role-specific keywords from the JD appear naturally in the CV summary +- [ ] Do not write a cover letter that re-summarises the CV — it must add context and motivation, not repeat bullet points + ## Example Trigger Phrases - "Help me apply for this job: [paste JD]" diff --git a/skills/job-description-writer/SKILL.md b/skills/job-description-writer/SKILL.md index effc6f5..94dd074 100644 --- a/skills/job-description-writer/SKILL.md +++ b/skills/job-description-writer/SKILL.md @@ -68,6 +68,14 @@ Nice to have (3-4 items): - [ ] Inclusive language review completed - [ ] No years-of-experience requirements unless legally required +## Anti-Patterns + +- [ ] Do not include years-of-experience requirements unless legally necessary — they exclude qualified candidates and may create legal risk +- [ ] Do not list "nice to have" items in the requirements section — separate mandatory from desirable clearly +- [ ] Do not use gendered or exclusionary language — run the inclusive language check before finalising +- [ ] Do not write a responsibilities section with more than 8 items — prioritise the most important duties +- [ ] Do not omit compensation range where legally required or culturally expected — hiding salary deters qualified candidates + ## Example Trigger Phrases - "Write a job description for a [role]" - "Create an inclusive job posting for [role]" diff --git a/skills/patient-communication/SKILL.md b/skills/patient-communication/SKILL.md index 60dd1f5..c33319b 100644 --- a/skills/patient-communication/SKILL.md +++ b/skills/patient-communication/SKILL.md @@ -92,6 +92,14 @@ Yours sincerely, [Name, Title, Department] - [ ] No Latin or acronyms without explanation - [ ] Disclaimer that clinical review is required before sending +## Anti-Patterns + +- [ ] Do not use medical jargon without a plain-English explanation — write for the patient, not the clinician +- [ ] Do not omit a clear "next steps" section — patients must know exactly what to do after reading +- [ ] Do not produce final content without flagging that clinical review is required before sending +- [ ] Do not write above a Grade 8 reading level without a compelling reason — accessibility is the default +- [ ] Do not include Latin abbreviations (e.g. "p.r.n.", "b.d.") without spelling them out — they are not universally understood + ## Example Trigger Phrases - "Write a patient letter about [topic]" - "Create a patient information leaflet for [procedure]" diff --git a/skills/performance-budget/SKILL.md b/skills/performance-budget/SKILL.md index 4848859..374815d 100644 --- a/skills/performance-budget/SKILL.md +++ b/skills/performance-budget/SKILL.md @@ -275,3 +275,11 @@ When a breach is detected, work through this checklist in order: - [ ] Budget breach response process names specific Slack channels and owners - [ ] Budget thresholds are anchored to baseline measurements or a justified target — not pulled from thin air - [ ] Per-journey targets are defined for critical user journeys, not just global averages + +## Anti-Patterns + +- [ ] Do not set budget thresholds without measuring a current baseline first — targets must be anchored to reality +- [ ] Do not define global averages only — critical user journeys need individual budgets as they may diverge significantly +- [ ] Do not omit CI enforcement — a performance budget that is not enforced in the build pipeline will not be respected +- [ ] Do not leave the breach response process without named owners and escalation channels +- [ ] Do not set budgets that apply only to one environment — production and staging targets should be documented separately if they differ diff --git a/skills/performance-review/SKILL.md b/skills/performance-review/SKILL.md index 7544990..5f6163b 100644 --- a/skills/performance-review/SKILL.md +++ b/skills/performance-review/SKILL.md @@ -108,6 +108,14 @@ Ask the user for these if not provided: - [ ] No vague phrases without evidence - [ ] Tone is professional and fair throughout +## Anti-Patterns + +- [ ] Do not inflate positive language to avoid difficult feedback — growth areas must be clearly stated, not buried +- [ ] Do not include feedback that isn't supported by specific examples — every development point needs evidence +- [ ] Do not write a review that only covers what happened in the last month — the full review period must be considered +- [ ] Do not omit development goals — a review without forward-looking guidance is incomplete +- [ ] Do not use language that could be read as discriminatory — avoid references to personality traits unrelated to work performance + ## Example Trigger Phrases - "Write a performance review for [name] based on these notes: [paste notes]" diff --git a/skills/pm-weekly-review/SKILL.md b/skills/pm-weekly-review/SKILL.md index 452eaa7..42f58d4 100644 --- a/skills/pm-weekly-review/SKILL.md +++ b/skills/pm-weekly-review/SKILL.md @@ -115,6 +115,14 @@ Ask the user for these if not provided: - [ ] Total length is under 400 words (skimmable in 3 minutes) - [ ] Reflection section is honest, not aspirational +## Anti-Patterns + +- [ ] Do not report metrics without comparing to target or the prior week — absolute numbers without context are not useful +- [ ] Do not list blockers without a named owner and proposed resolution — unowned blockers stay blocked +- [ ] Do not write a weekly review that is longer than one page — it must be scannable in under 2 minutes +- [ ] Do not include more than 3 priorities for next week — a list of 8 "top priorities" means nothing is prioritised +- [ ] Do not skip the insights section — observations that inform future decisions are a PM's key value add + ## Guidelines - Keep the whole document under 400 words — if stakeholders won't read it, it doesn't exist diff --git a/skills/pptx-slide-auditor/SKILL.md b/skills/pptx-slide-auditor/SKILL.md index 53586bf..4f87066 100644 --- a/skills/pptx-slide-auditor/SKILL.md +++ b/skills/pptx-slide-auditor/SKILL.md @@ -82,6 +82,14 @@ Order by: fixes before handoff (critical) > consistency fixes (high) > polish (m - [ ] Audience-appropriate concerns flagged explicitly - [ ] Slides without issues are listed briefly, not ignored +## Anti-Patterns + +- [ ] Do not flag stylistic preferences as issues — only report genuine layout problems, overflow, and consistency errors +- [ ] Do not produce a flat list of issues — group by severity (Critical / Major / Minor) so fixes can be prioritised +- [ ] Do not skip slides without commenting — every slide must have an explicit pass or issue status +- [ ] Do not suggest redesigning content — the audit scope is layout, consistency, and readability, not messaging +- [ ] Do not report the same issue type repeatedly across slides without summarising the pattern — consolidate repeated issues + ## Example Trigger Phrases - "Audit this slide deck before my board meeting" - "Review this PowerPoint for layout issues"