fix(skills): add Anti-Patterns and fixes for partial batch 2 skills

https://claude.ai/code/session_01MuGKn3a3Gbqoe8uM5Lmuqt

skills/experiment-designer/SKILL.md

@@ -67,3 +67,11 @@ Ask the user for these if not provided:
 - [ ] Test was not stopped early (or flagged clearly if it was)
 - [ ] Practical significance assessed separately from statistical significance
 - [ ] Sample ratio mismatch is checked in results interpretation
+
+## Anti-Patterns
+
+- [ ] Do not define success criteria after seeing preliminary results — post-hoc success definitions are HARKing (Hypothesising After Results are Known) and invalidate the experiment
+- [ ] Do not stop a test early because the result looks significant — early stopping dramatically inflates false positive rates; the test must run to the planned sample size
+- [ ] Do not treat statistical significance as the same as practical significance — a p < 0.05 result with a 0.1% lift is real but may not be worth shipping
+- [ ] Do not run the same experiment on the same population multiple times without correction — multiple testing inflates the chance of a false positive proportionally
+- [ ] Do not use more than one primary metric — multiple primary metrics require multiple hypothesis corrections and make the ship/kill decision ambiguous

skills/feature-flag-guide/SKILL.md

@@ -367,3 +367,11 @@ All flag changes in production must be traceable. Ensure the following are confi
 - [ ] Stale flag detection runs automatically and results are reviewed weekly
 - [ ] Code review checklist includes: "Does this PR introduce a flag? If yes, is the creation checklist complete?"
 - [ ] At least one person other than the flag owner knows how to disable any given flag in an emergency
+
+## Anti-Patterns
+
+- [ ] Do not create release flags without a cleanup date — flags without expiry dates become permanent technical debt that accumulates silently until the codebase is unmaintainable
+- [ ] Do not skip monitoring setup for flags between 1–99% rollout — a partially-rolled-out flag without metric comparison is a risk without a sensor
+- [ ] Do not nest flags inside other flags — compound flag logic makes cleanup nearly impossible and creates untestable code paths
+- [ ] Do not allow flag owners to leave the team without reassigning ownership — orphan flags with no owner never get cleaned up
+- [ ] Do not use feature flags as a permanent configuration system — flags that have been at 100% or 0% for more than 30 days must be cleaned up; using flags as permanent config couples business logic to a feature flag platform

skills/partnership-proposal/SKILL.md

@@ -226,3 +226,11 @@ How we'll know the partnership is working:
 - "Create a reseller partnership proposal for [Company]"
 - "Build the business case for a strategic partnership with [Partner]"
 - "Structure a technology integration partnership proposal"
+
+## Anti-Patterns
+
+- [ ] Do not write the value proposition from your own perspective — the "For Partner" section must be written from the partner's point of view, in the language of their goals and their customers
+- [ ] Do not leave commercial terms as structure without numbers — a proposal that says "revenue share" without stating the percentage is not a proposal, it is a conversation opener
+- [ ] Do not omit the "What we're not proposing" section — leaving unstated assumptions creates misaligned expectations that derail negotiations later
+- [ ] Do not set success metrics unilaterally — metrics that only your company controls or cares about will not earn partner commitment
+- [ ] Do not write a go-to-market plan with "TBD" owners — every activity must have a named owner on at least one side before the proposal goes out

skills/sql-query-explainer/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: sql-query-explainer
-description: "Explain, optimise, or translate SQL queries into plain language. Use when asked to explain a SQL query, optimise slow SQL, write a data dictionary, translate SQL to plain English for non-technical stakeholders, or review a query for correctness and performance. Works across PostgreSQL, MySQL, BigQuery, Snowflake, and standard SQL."
+description: "Explains, optimises, writes, and documents SQL queries. Use when asked to explain a SQL query, optimise slow SQL, translate SQL to plain English for non-technical stakeholders, write a query from a natural language description, or produce query documentation. Produces plain-English explanations, annotated optimised queries, or a data dictionary covering output shape, assumptions, and known limitations. Works across PostgreSQL, MySQL, BigQuery, Snowflake, and standard SQL."
 ---
 
 # SQL Query Explainer Skill