From f170eed437ba0a66a0fb319706e71ed9d925bb8c Mon Sep 17 00:00:00 2001 From: Mohit Date: Mon, 8 Jun 2026 12:57:05 +0000 Subject: [PATCH] fix(skills): add Anti-Patterns and fix descriptions for remaining skills (batch 2) Processed 24 skills: pr-description-writer through tax-planning-checklist. Added Anti-Patterns sections to all 24 skills. Added Required Inputs section to product-launch-checklist. Rewrote descriptions for retro-analysis, substack-notes-scraper, and sycophancy-challenger. https://claude.ai/code/session_01MuGKn3a3Gbqoe8uM5Lmuqt --- skills/pr-description-writer/SKILL.md | 8 ++++++++ skills/prd-template/SKILL.md | 8 ++++++++ skills/press-release/SKILL.md | 8 ++++++++ skills/pricing-strategy/SKILL.md | 8 ++++++++ skills/process-documentation/SKILL.md | 8 ++++++++ skills/product-health-analysis/SKILL.md | 8 ++++++++ skills/product-launch-checklist/SKILL.md | 17 +++++++++++++++++ skills/product-positioning-doc/SKILL.md | 8 ++++++++ skills/project-status-report/SKILL.md | 8 ++++++++ skills/proposal-writer/SKILL.md | 8 ++++++++ skills/qbr-deck/SKILL.md | 8 ++++++++ skills/raci-matrix/SKILL.md | 8 ++++++++ skills/redundancy-consultation/SKILL.md | 8 ++++++++ skills/renewal-playbook/SKILL.md | 8 ++++++++ skills/research-protocol/SKILL.md | 8 ++++++++ skills/retention-analysis/SKILL.md | 8 ++++++++ skills/retro-analysis/SKILL.md | 10 +++++++++- skills/stakeholder-influence-mapper/SKILL.md | 8 ++++++++ skills/stakeholder-update/SKILL.md | 8 ++++++++ skills/strategic-narrative-generator/SKILL.md | 8 ++++++++ skills/substack-notes-scraper/SKILL.md | 10 +++++++++- skills/sycophancy-challenger/SKILL.md | 10 +++++++++- skills/system-design-interview/SKILL.md | 8 ++++++++ skills/tax-planning-checklist/SKILL.md | 8 ++++++++ 24 files changed, 204 insertions(+), 3 deletions(-) diff --git a/skills/pr-description-writer/SKILL.md b/skills/pr-description-writer/SKILL.md index 19ee525..8cf622c 100644 --- a/skills/pr-description-writer/SKILL.md +++ b/skills/pr-description-writer/SKILL.md @@ -82,6 +82,14 @@ Flag anything that warrants extra attention: - [ ] Testing steps are reproducible by someone unfamiliar with the code - [ ] For high-risk PRs, Reviewer Notes flags at least one specific area of concern or deliberate trade-off; for low-risk PRs, Reviewer Notes is either omitted or kept to one line +## Anti-Patterns + +- [ ] Do not write a description that only restates what changed — explain why the change was made +- [ ] Do not skip the testing steps — reviewers need to know how to verify the change works +- [ ] Do not omit the reviewer notes for high-risk PRs — flag deliberate trade-offs and areas needing careful review +- [ ] Do not describe implementation details that are obvious from the diff — add context that the diff cannot convey +- [ ] Do not produce a single paragraph — structure with headers so reviewers can navigate to what they need + ## Usage Examples - "Write a PR description for these changes" + [paste diff or description] - "Draft a pull request for [feature]" diff --git a/skills/prd-template/SKILL.md b/skills/prd-template/SKILL.md index 023daa1..542c342 100644 --- a/skills/prd-template/SKILL.md +++ b/skills/prd-template/SKILL.md @@ -110,6 +110,14 @@ Format: "As a [user type], I want to [action] so that [benefit]" - [ ] Open questions are listed explicitly - [ ] Implementation plan distinguishes MVP from future phases +## Anti-Patterns + +- [ ] Do not write requirements from the company's perspective — every requirement must trace back to a user need +- [ ] Do not include vague requirements like "the system should be fast" — every requirement must be testable +- [ ] Do not conflate MVP with future phases — be explicit about what is and is not in scope for the first release +- [ ] Do not leave success metrics as percentages without baselines — specify the current state and the target +- [ ] Do not skip open questions — unresolved assumptions are risks; surfacing them is the PM's job + ## Example PRD Opening ``` diff --git a/skills/press-release/SKILL.md b/skills/press-release/SKILL.md index e1c85c5..4f96fe4 100644 --- a/skills/press-release/SKILL.md +++ b/skills/press-release/SKILL.md @@ -72,6 +72,14 @@ Would a journalist care? Is the headline the full story? Is there a human angle? - [ ] Boilerplate is factual, not promotional - [ ] Embargo date and media contact are included +## Anti-Patterns + +- [ ] Do not bury the news — the most important information must appear in the first paragraph (inverted pyramid) +- [ ] Do not use promotional language or superlatives — press releases must read as news, not advertising copy +- [ ] Do not omit the boilerplate — every press release needs the standard "About [Company]" paragraph at the end +- [ ] Do not forget the embargo date and media contact — journalists need both to use the release +- [ ] Do not write a headline longer than 12 words — it must be scannable and specific + ## Example Trigger Phrases - "Write a press release announcing [news]" - "Draft a media statement about [event]" diff --git a/skills/pricing-strategy/SKILL.md b/skills/pricing-strategy/SKILL.md index a1783d0..7d2f3bd 100644 --- a/skills/pricing-strategy/SKILL.md +++ b/skills/pricing-strategy/SKILL.md @@ -129,6 +129,14 @@ Ask the user for these if not provided: - [ ] Counter-metrics are defined to catch perverse incentives - [ ] Risks have specific mitigations (not just listed) +## Anti-Patterns + +- [ ] Do not base pricing solely on cost-plus — pricing must reflect value delivered to the customer +- [ ] Do not design tiers where the middle tier is clearly worse value — it undermines trust and pushes customers to extremes +- [ ] Do not change pricing without a migration plan for existing customers — surprise price changes cause churn +- [ ] Do not set enterprise pricing as "contact us" without a floor — it deters self-serve evaluation and qualification +- [ ] Do not skip competitive positioning — pricing in isolation from the market is incomplete strategy + ## Guidelines - Never price based on cost — price based on value delivered to the customer diff --git a/skills/process-documentation/SKILL.md b/skills/process-documentation/SKILL.md index 937c8c9..e907edb 100644 --- a/skills/process-documentation/SKILL.md +++ b/skills/process-documentation/SKILL.md @@ -83,6 +83,14 @@ Next review due: [Date] - [ ] Escalation path is named (specific people or roles, not just "your manager") - [ ] Review date is set +## Anti-Patterns + +- [ ] Do not write steps without specifying who is responsible for each — ownership must be explicit throughout +- [ ] Do not omit the escalation path — every process must say what happens when something goes wrong +- [ ] Do not document the ideal process if the real process differs — document reality, then note improvements separately +- [ ] Do not skip edge cases and exceptions — they are where most process failures actually occur +- [ ] Do not produce documentation without a review date — undated process docs quickly become incorrect + ## Example Trigger Phrases - "Document this process: [description]" - "Write a process guide for [workflow]" diff --git a/skills/product-health-analysis/SKILL.md b/skills/product-health-analysis/SKILL.md index 32aaa2a..9c58a08 100644 --- a/skills/product-health-analysis/SKILL.md +++ b/skills/product-health-analysis/SKILL.md @@ -57,3 +57,11 @@ Analyse across four layers: - [ ] Every flagged metric has a root cause hypothesis, not just "it dropped" - [ ] Observations are written for a non-technical stakeholder (no raw query language or data jargon) - [ ] Overall health rating is justified with specific evidence + +## Anti-Patterns + +- [ ] Do not report a single aggregate metric without segment breakdowns — averages hide opposing trends +- [ ] Do not flag a metric as healthy just because it is above the target — check if the target itself is meaningful +- [ ] Do not list metric movements without root cause hypotheses — observations without explanations are not analysis +- [ ] Do not mix product health metrics with business KPIs without explaining the relationship between them +- [ ] Do not omit recommended actions — a health report that only describes problems without prioritised next steps is incomplete diff --git a/skills/product-launch-checklist/SKILL.md b/skills/product-launch-checklist/SKILL.md index 0741653..e07d6e4 100644 --- a/skills/product-launch-checklist/SKILL.md +++ b/skills/product-launch-checklist/SKILL.md @@ -7,6 +7,15 @@ description: "Generate a comprehensive pre-launch, launch day, and post-launch c Never launch without checking everything. Generate a complete, role-assigned checklist covering pre-launch readiness, launch day execution, and post-launch monitoring. +## Required Inputs + +Ask the user for these if not provided: +- **Launch name** and planned launch date +- **Launch tier** (1 = major product launch, 2 = significant feature release, 3 = incremental update) +- **Team members and their roles** (engineering lead, PM, marketing, support, etc.) +- **Feature description** (what is being launched) +- **Rollback capability** (can this be feature-flagged or reverted quickly?) + ## How to Use This Skill Provide: @@ -117,6 +126,14 @@ The skill generates a tiered checklist. Tier 3 launches use only the Essentials - [ ] Feature flag expansion is staged (5% → 50% → 100%), not all-at-once - [ ] Post-launch retrospective is scheduled at launch time +## Anti-Patterns + +- [ ] Do not apply a Tier 1 checklist to an incremental update — tier the launch appropriately before generating the checklist +- [ ] Do not launch on a Friday without confirmed weekend engineering coverage +- [ ] Do not leave the Go/No-Go decision owner as "the team" — it must be a named individual +- [ ] Do not skip the rollback plan for Tier 1 and 2 launches — know the revert time before going live +- [ ] Do not close the launch without scheduling the post-launch retrospective — it must be booked at launch time, not after + ## Guidelines - The Go/No-Go decision must have a named owner — "the team" is not an owner diff --git a/skills/product-positioning-doc/SKILL.md b/skills/product-positioning-doc/SKILL.md index 7640161..bb43044 100644 --- a/skills/product-positioning-doc/SKILL.md +++ b/skills/product-positioning-doc/SKILL.md @@ -212,6 +212,14 @@ Positioning only works if it's implemented consistently: - [ ] Persona messaging uses the buyer's language, not the company's - [ ] At least two people from product, marketing, and sales have reviewed and approved +## Anti-Patterns + +- [ ] Do not write positioning that could describe any competitor — differentiation must be specific, provable, and hard to copy +- [ ] Do not mix category design with category entry — know whether you are creating a new category or competing in an existing one +- [ ] Do not create persona messaging that uses the same headline for all personas — each persona has different priorities +- [ ] Do not include proof points that are claims without evidence — every proof point needs a supporting data point or reference +- [ ] Do not skip the "not for" section — defining who this is not for sharpens targeting and prevents off-persona deals + ## Example Trigger Phrases - "Write a positioning document for [product]" diff --git a/skills/project-status-report/SKILL.md b/skills/project-status-report/SKILL.md index 9676ff3..d05e19c 100644 --- a/skills/project-status-report/SKILL.md +++ b/skills/project-status-report/SKILL.md @@ -111,6 +111,14 @@ RAG definitions: - [ ] Milestones are binary (complete or not complete — no "85% done") - [ ] Executive summary can stand alone for a stakeholder who reads nothing else +## Anti-Patterns + +- [ ] Do not rate project health as Green while listing unresolved critical blockers +- [ ] Do not report milestone progress as a percentage — milestones are binary: complete or not complete +- [ ] Do not bury risks at the bottom — if something is high risk, it belongs in the executive summary +- [ ] Do not leave decisions required without specifying who must decide and by when +- [ ] Do not write an executive summary that requires reading the full report to understand — it must stand alone + ## Example Trigger Phrases - "Write a project status report for [project]" - "Generate a RAG status update for [project]" diff --git a/skills/proposal-writer/SKILL.md b/skills/proposal-writer/SKILL.md index ce40ee8..f71e8ca 100644 --- a/skills/proposal-writer/SKILL.md +++ b/skills/proposal-writer/SKILL.md @@ -94,6 +94,14 @@ Writes commercial proposals that win business — structured around the prospect - [ ] Next steps include a specific date and named action - [ ] "Valid until" date is included to create urgency +## Anti-Patterns + +- [ ] Do not lead with the solution before establishing that the problem is understood — the proposal must demonstrate problem comprehension first +- [ ] Do not use vague investment language like "competitive pricing" — every proposal must state a specific price or range +- [ ] Do not omit a "not included" section — undefined scope leads to disputes after the proposal is accepted +- [ ] Do not forget a "valid until" date — proposals without expiry create awkward situations and stale pricing +- [ ] Do not list next steps without naming who is responsible for each and what the expected timeline is + ## Example Trigger Phrases - "Write a proposal for [prospect] to [solve their problem]" - "Draft a statement of work for [project]" diff --git a/skills/qbr-deck/SKILL.md b/skills/qbr-deck/SKILL.md index 0c5ea5e..b747ccb 100644 --- a/skills/qbr-deck/SKILL.md +++ b/skills/qbr-deck/SKILL.md @@ -216,3 +216,11 @@ Prompt questions: - [ ] Roadmap preview links each item to a customer goal - [ ] Mutual commitments section has real owners on both sides - [ ] Customer has at least 20 minutes of airtime in the agenda + +## Anti-Patterns + +- [ ] Do not fill the QBR with product activity metrics — lead with business outcomes the customer cares about +- [ ] Do not present a roadmap without linking each item to a customer goal — vendor priorities are not a QBR agenda +- [ ] Do not run a QBR as a one-sided presentation — it must include structured time for the customer to speak +- [ ] Do not close a QBR without documented mutual commitments with named owners on both sides +- [ ] Do not skip the "what's not working" slide — suppressing problems erodes trust and misses renewal risks diff --git a/skills/raci-matrix/SKILL.md b/skills/raci-matrix/SKILL.md index 7225a32..02e145a 100644 --- a/skills/raci-matrix/SKILL.md +++ b/skills/raci-matrix/SKILL.md @@ -151,6 +151,14 @@ Please review the full matrix here: [Link]. Raise any concerns by [Date] — aft - [ ] A communication plan exists to share the RACI with all involved parties - [ ] Decision map covers the top 5–10 highest-stakes decisions in the project +## Anti-Patterns + +- [ ] Do not assign more than one Accountable per task — shared accountability means no accountability +- [ ] Do not create a RACI with more than 5–6 roles — it becomes unreadable and unenforceable +- [ ] Do not include tasks so broad that the RACI cannot be acted upon — break down to decision-level granularity +- [ ] Do not skip the conflict resolution process — RACI matrices without a process for disputes are unused after the first disagreement +- [ ] Do not confuse Responsible with Accountable — document the distinction clearly for each role + ## Example Trigger Phrases - "Build a RACI matrix for our product launch" diff --git a/skills/redundancy-consultation/SKILL.md b/skills/redundancy-consultation/SKILL.md index 757e9e4..63254a2 100644 --- a/skills/redundancy-consultation/SKILL.md +++ b/skills/redundancy-consultation/SKILL.md @@ -71,6 +71,14 @@ WARNING: Take advice from an employment lawyer or qualified HR professional befo - [ ] Statutory redundancy pay guidance included - [ ] Legal advice disclaimer is prominent +## Anti-Patterns + +- [ ] Do not proceed without a prominent disclaimer that qualified HR and legal advice is required before taking any action +- [ ] Do not use template letters without customising them for the specific individual and situation +- [ ] Do not omit the genuine exploration of alternatives — redundancy consultation must consider alternatives before confirming decisions +- [ ] Do not leave out statutory redundancy pay guidance — employees have legal entitlements that must be referenced +- [ ] Do not conduct a redundancy process without documenting the selection criteria and scoring — undocumented decisions create legal risk + ## Example Trigger Phrases - "Help me structure a redundancy consultation" - "Draft an at-risk letter for [role]" diff --git a/skills/renewal-playbook/SKILL.md b/skills/renewal-playbook/SKILL.md index 8828e81..32b9dc2 100644 --- a/skills/renewal-playbook/SKILL.md +++ b/skills/renewal-playbook/SKILL.md @@ -181,6 +181,14 @@ Prepare for the most likely objections: - [ ] Timeline starts at least 90 days before renewal date - [ ] Objection responses are specific to this account, not generic +## Anti-Patterns + +- [ ] Do not start renewal conversations less than 90 days before the renewal date for accounts over $50K ARR +- [ ] Do not build a renewal strategy without first honestly assessing account health — wishful thinking leads to last-minute churn +- [ ] Do not treat all renewal objections as negotiating tactics — some objections signal genuine dissatisfaction that requires resolution first +- [ ] Do not offer discounts as the first response to price objections — explore value gaps before reducing price +- [ ] Do not close the renewal without confirming the expansion opportunity — every renewal is also an expansion conversation + ## Example Trigger Phrases - "Build a renewal playbook for [Account Name] renewing in [Month]" diff --git a/skills/research-protocol/SKILL.md b/skills/research-protocol/SKILL.md index e7a1901..19d004f 100644 --- a/skills/research-protocol/SKILL.md +++ b/skills/research-protocol/SKILL.md @@ -92,6 +92,14 @@ Qualitative: [Framework — e.g. Braun & Clarke], [quality assurance] - [ ] Analysis plan is pre-specified (not "to be determined") - [ ] Timeline includes all phases from ethics approval to write-up +## Anti-Patterns + +- [ ] Do not write an analysis plan as "to be determined" — the analysis approach must be pre-specified before data collection +- [ ] Do not skip the ethical considerations section — all research involving human participants requires ethical review +- [ ] Do not define research questions so broadly that the study cannot answer them within scope and budget +- [ ] Do not conflate the research question with the hypothesis — state them separately and clearly +- [ ] Do not omit sample size justification — an underpowered study wastes resources and produces inconclusive results + ## Example Trigger Phrases - "Write a research protocol for [study]" - "Help me design a study to investigate [question]" diff --git a/skills/retention-analysis/SKILL.md b/skills/retention-analysis/SKILL.md index 15c6e32..14a11ce 100644 --- a/skills/retention-analysis/SKILL.md +++ b/skills/retention-analysis/SKILL.md @@ -126,6 +126,14 @@ Ask the user for these if not provided: - [ ] Churned user interviews are recommended (not just data analysis) - [ ] Monitoring plan includes an alert threshold +## Anti-Patterns + +- [ ] Do not recommend "improve onboarding" without specifying what specific step to change and why +- [ ] Do not analyse retention without segmenting by cohort — aggregate retention curves hide cohort-specific patterns +- [ ] Do not treat DAU/MAU below 5% as a retention problem — at that level, it is a product-market fit problem +- [ ] Do not skip qualitative research — churned user interviews reveal reasons that quantitative data cannot +- [ ] Do not set a monitoring alert without specifying the threshold that triggers it + ## Guidelines - Never recommend "improve onboarding" without specifying *what* to change and *why* diff --git a/skills/retro-analysis/SKILL.md b/skills/retro-analysis/SKILL.md index 512e545..a92a54d 100644 --- a/skills/retro-analysis/SKILL.md +++ b/skills/retro-analysis/SKILL.md @@ -1,6 +1,6 @@ --- name: retro-analysis -description: "Analyse sprint delivery data and produce a structured retrospective brief. Use when asked to run a retrospective, analyse sprint data, prepare a retro brief, or turn sprint metrics into discussion prompts. Produces a data-grounded retrospective brief with completion stats, pattern analysis, Start/Stop/Continue prompts, and one concrete experiment for next sprint." +description: "Analyses sprint delivery data and produces a structured retrospective brief. Use when asked to run a retrospective, analyse sprint data, prepare a retro brief, or turn sprint metrics into discussion prompts. Produces a data-grounded retrospective brief with completion stats, pattern analysis, Start/Stop/Continue prompts, and one concrete experiment for next sprint." --- # Retrospective Analysis Skill @@ -51,3 +51,11 @@ Ask the user for these if not provided: - [ ] Carry-over analysis identifies the ticket type or cause, not just the count - [ ] Data observations don't assign blame — they describe patterns - [ ] Velocity trend is mentioned in context (is this a one-off or a pattern?) + +## Anti-Patterns + +- [ ] Do not assign blame to individuals in the retrospective brief — observations must describe patterns, not people +- [ ] Do not produce Start/Stop/Continue prompts that are vague categories — each must name a specific behaviour +- [ ] Do not recommend an experiment that cannot be completed within one sprint — small, testable experiments only +- [ ] Do not treat carry-over tickets as a velocity problem without first identifying the root cause category +- [ ] Do not run the same retrospective format every sprint — vary the format to prevent engagement fatigue diff --git a/skills/stakeholder-influence-mapper/SKILL.md b/skills/stakeholder-influence-mapper/SKILL.md index d8ae045..1793382 100644 --- a/skills/stakeholder-influence-mapper/SKILL.md +++ b/skills/stakeholder-influence-mapper/SKILL.md @@ -58,3 +58,11 @@ Ask the user for these if not provided: - [ ] Each stakeholder's talking points lead with their concern, not your agenda - [ ] At least one "do not approach until X is aligned" flag is considered - [ ] The ask from each stakeholder is a single, specific thing (not a vague "support") + +## Anti-Patterns + +- [ ] Do not approach high-influence blockers before aligning their sponsors — approach order determines outcome +- [ ] Do not create talking points that lead with your agenda — always lead with the stakeholder's stated concern +- [ ] Do not treat every stakeholder as equally important — focus depth on the decision-makers and key influencers +- [ ] Do not omit the "do not approach until X is aligned" flags — sequencing mistakes can permanently close doors +- [ ] Do not build the map based only on org chart position — influence often lives outside formal authority diff --git a/skills/stakeholder-update/SKILL.md b/skills/stakeholder-update/SKILL.md index d4cd429..87c1a9b 100644 --- a/skills/stakeholder-update/SKILL.md +++ b/skills/stakeholder-update/SKILL.md @@ -234,3 +234,11 @@ Only include issues that matter at executive level. - [ ] Every risk has a mitigation and a "help needed" flag if stakeholder action is required - [ ] Decisions needed have specific options and a clear recommendation - [ ] Total length is under 1 page / 2 minutes reading time + +## Anti-Patterns + +- [ ] Do not bury the status assessment at the bottom — BLUF means the most important information comes first +- [ ] Do not report metrics without a target or prior-period comparison — raw numbers without context are not useful +- [ ] Do not list risks without mitigation actions and clear flags for stakeholder help needed +- [ ] Do not write decisions needed as questions without providing a clear recommendation — executives need options, not open-ended questions +- [ ] Do not allow the update to exceed one page — if it requires more, the message needs editing, not expanding diff --git a/skills/strategic-narrative-generator/SKILL.md b/skills/strategic-narrative-generator/SKILL.md index 85b6a13..7d282c8 100644 --- a/skills/strategic-narrative-generator/SKILL.md +++ b/skills/strategic-narrative-generator/SKILL.md @@ -67,3 +67,11 @@ Ask the user for these if not provided: - [ ] Each theme has a specific, measurable metric (not "improve engagement") - [ ] Progression story shows causal links between quarters, not just chronological listing - [ ] "Not on the roadmap" section includes at least 2 items with clear rationale + +## Anti-Patterns + +- [ ] Do not produce a narrative that lists initiatives chronologically without showing causal progression — the story must show why each phase enables the next +- [ ] Do not use abstract strategic language that cannot be repeated by a non-technical listener — test whether someone could explain it back without the document +- [ ] Do not omit the "what's not on the roadmap" section — what you are choosing not to do is as important as what you are doing +- [ ] Do not set themes without measurable metrics — a theme without a metric cannot be tracked or held to account +- [ ] Do not skip the hard questions section — preparing for objections in advance is the purpose of the narrative exercise diff --git a/skills/substack-notes-scraper/SKILL.md b/skills/substack-notes-scraper/SKILL.md index 971edba..f64df87 100644 --- a/skills/substack-notes-scraper/SKILL.md +++ b/skills/substack-notes-scraper/SKILL.md @@ -1,6 +1,6 @@ --- name: substack-notes-scraper -description: Scrapes a Substack Notes page and exports engagement data (likes, comments, restacks) to a formatted .xlsx file with conditional formatting and summary stats. +description: "Scrapes a Substack Notes page and exports engagement data to a formatted .xlsx file. Use when asked to download, analyse, or export Substack Notes performance data including likes, comments, and restacks. Produces a formatted spreadsheet with conditional formatting, summary stats, and per-note engagement metrics." --- # Substack Notes Scraper @@ -167,6 +167,14 @@ After generating the file, report: --- +## Anti-Patterns + +- [ ] Do not proceed without a valid Substack handle or profile URL — scraping without a specific target cannot be completed +- [ ] Do not ignore rate-limit responses from Substack — implement backoff and reduce request frequency before retrying +- [ ] Do not export data without conditional formatting and summary stats — raw data without visualisation is not the expected output +- [ ] Do not attempt to access private or subscriber-only notes — this skill is for public Notes content only +- [ ] Do not produce output without a clear date range filter — undated exports make trend analysis impossible + ## Example Trigger Phrases - "Scrape my Substack Notes and export to Excel — my handle is @handle, last 60 days" diff --git a/skills/sycophancy-challenger/SKILL.md b/skills/sycophancy-challenger/SKILL.md index b70a00c..505a9d5 100644 --- a/skills/sycophancy-challenger/SKILL.md +++ b/skills/sycophancy-challenger/SKILL.md @@ -1,6 +1,6 @@ --- name: sycophancy-challenger -description: Flips Claude's default from "find reasons you're right" to "find reasons you're wrong." A genuine thinking partner, not a mirror with grammar. Use before high-stakes decisions, plans, assumptions, or pitches you haven't stress-tested. +description: "Flips Claude's default from validation to adversarial critique. Use before high-stakes decisions, plans, assumptions, or pitches you haven't stress-tested. Produces structured challenges, steelmanned counter-arguments, and the strongest case against your position — a genuine thinking partner, not a mirror." --- # Sycophancy Challenger @@ -143,6 +143,14 @@ These prohibitions do more work than the rules above. Follow them absolutely: --- +## Anti-Patterns + +- [ ] Do not open with a softening phrase or acknowledgment before the challenge — the first sentence must be the critique +- [ ] Do not retreat from a position when the user pushes back without providing new evidence — update only when genuinely persuaded +- [ ] Do not invent flaws — every criticism must connect to something real in what the user described +- [ ] Do not provide a list of weak objections — identify the single strongest case against the idea +- [ ] Do not end the session because the user seems satisfied — end only when something genuinely changed or was defended + ## Example Trigger Phrases - "Use the sycophancy-challenger skill — here's my plan: [describe it]" diff --git a/skills/system-design-interview/SKILL.md b/skills/system-design-interview/SKILL.md index 5c83362..3e81e14 100644 --- a/skills/system-design-interview/SKILL.md +++ b/skills/system-design-interview/SKILL.md @@ -125,6 +125,14 @@ Things to tackle in production but out of scope for this design session: - [ ] Trade-offs section is honest (not just benefits of chosen approach) - [ ] Data flow is described end-to-end for the critical path +## Anti-Patterns + +- [ ] Do not jump to solutions before clarifying requirements — always establish functional and non-functional requirements first +- [ ] Do not present a design without discussing trade-offs — every architecture decision has costs and benefits that must be acknowledged +- [ ] Do not use vague capacity estimates — show the actual calculation (QPS, storage bytes, bandwidth) not just "this handles scale" +- [ ] Do not design for unlimited scale by default — match the design to the requirements stated +- [ ] Do not skip the data model — a system design without entity definitions and data flow is incomplete + ## Usage Examples - "Help me answer a system design interview: [question]" - "Design [system] for a system design interview" diff --git a/skills/tax-planning-checklist/SKILL.md b/skills/tax-planning-checklist/SKILL.md index 76e3103..633736a 100644 --- a/skills/tax-planning-checklist/SKILL.md +++ b/skills/tax-planning-checklist/SKILL.md @@ -120,6 +120,14 @@ Based on the above, prioritise these before year-end: - [ ] Disclaimer is prominent — this is a framework, not tax advice - [ ] Threshold figures are flagged as requiring verification for current tax year +## Anti-Patterns + +- [ ] Do not provide specific tax advice — always recommend qualified tax advice and note this prominently +- [ ] Do not present threshold figures as definitive without noting they require verification for the current tax year +- [ ] Do not produce a generic checklist without tailoring it to the entity type (individual, sole trader, limited company) +- [ ] Do not omit timing-critical items — some reliefs require action before year-end and deadlines must be called out +- [ ] Do not conflate UK and non-UK tax rules — clarify jurisdiction before generating any checklist + ## Example Trigger Phrases - "Give me a tax planning checklist for [year-end / my situation]"