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

Processed 29 skills: content-calendar through pptx-slide-auditor.
Added Anti-Patterns sections to all 29 skills.
Rewrote descriptions for instagram-post-downloader and job-application.

https://claude.ai/code/session_01MuGKn3a3Gbqoe8uM5Lmuqt

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

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"

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

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

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

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"

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

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

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"

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

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

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"

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

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

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

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

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"

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"

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

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

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"

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

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

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

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

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

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

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

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"