@ericrisco/rsc 0.1.52 → 0.1.54

package/skills/newsletter/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: newsletter
-description: "Use when running an email newsletter as a recurring publication — writing the subject line + preview text, structuring an issue so opens turn into clicks, the welcome/onboarding sequence, send cadence and engagement segmentation, growth loops (referral, signup incentive, double opt-in), and a metric scorecard that survives Apple Mail Privacy Protection. Triggers: 'write the newsletter subject line', 'my newsletter gets opened but nobody clicks', 'set up a welcome sequence', 'grow my newsletter list', 'newsletter referral program', 'how often should I send', 'what metrics matter now that opens are fake', 'click-to-open rate', 'escriu la newsletter d'aquesta setmana', 'campaña de newsletter que convierta'. NOT the one-off product launch or nurture campaign (that is marketing), NOT the SPF/DKIM/DMARC plumbing under the send (that is email-deliverability)."
+description: "Use when running an email newsletter as a recurring publication — subject + preview pair, issues that turn opens into clicks, the welcome sequence, cadence and engagement tiering, growth loops, and a post-Apple-MPP click scorecard. NOT one-off launch or nurture sends (that is `marketing`), NOT SPF/DKIM/DMARC (that is `email-deliverability`)."
 tags: [newsletter, email, growth, copywriting, retention-metrics]
 recommends: [marketing, email-deliverability, brand-voice, landing-copy, ab-testing]
 profiles: []
@@ -11,29 +11,19 @@ origin: risco
 
 Run the newsletter as a **product you ship on a cadence**, not a one-off send. The job is the system around the recurring issue: the subject + preview that earns the open, the issue body that earns the click, the welcome sequence that activates a new subscriber, the cadence and segmentation that keep the list healthy, the growth loops that compound it, and a scorecard that still tells the truth after Apple broke open rates. Every send is one episode of an ongoing show — design the show, not the episode.
 
-## When to use
-
-- Writing the subject line + preview text for an issue and fitting them to inbox truncation.
-- Structuring a recurring issue so opens convert: hook on the first screen, scannable body, one CTA.
-- Writing the welcome / onboarding sequence a confirmed subscriber gets.
-- Planning send cadence, frequency, and engagement-based segmentation.
-- Designing a growth loop: referral program, signup incentive / lead magnet, double opt-in.
-- Choosing which metrics to trust now that Apple MPP inflates opens; building the scorecard.
-- Rescuing a newsletter with high opens but no clicks, or a quietly decaying engaged-reader count.
-
 ## When NOT to use — route instead
 
 | The ask | Route to |
 |---|---|
 | One-off product launch announcement or campaign drip nurture | `../marketing/SKILL.md` |
-| Mail lands in spam; set up SPF / DKIM / DMARC, tracking domain, reputation | `email-deliverability` |
+| Mail lands in spam; set up SPF / DKIM / DMARC, tracking domain, reputation | `../email-deliverability/SKILL.md` |
 | Write the subscribe / opt-in landing page copy | `../landing-copy/SKILL.md` |
 | Define the house voice, tone, and vocabulary the newsletter speaks in | `../brand-voice/SKILL.md` |
-| Win back / reactivate lapsed *paying customers* (lifecycle, not readers) | `retention` |
+| Win back / reactivate lapsed *paying customers* (lifecycle, not readers) | `../retention/SKILL.md` |
 | Produce the underlying long-form articles the issue links out to | `../content-engine/SKILL.md` |
-| Sample size / significance / MDE math for the test itself | `ab-testing` |
-| Source or scrape new contacts; prospect an un-opted-in list | `lead-gen`, `../cold-outreach/SKILL.md` |
-| Actually wire the send through an ESP / Gmail API and schedule it | `email-connector`, `google-workspace` |
+| Sample size / significance / MDE math for the test itself | `../ab-testing/SKILL.md` |
+| Source or scrape new contacts; prospect an un-opted-in list | `../lead-gen/SKILL.md`, `../cold-outreach/SKILL.md` |
+| Actually wire the send through an ESP / Gmail API and schedule it | `../email-connector/SKILL.md`, `../google-workspace/SKILL.md` |
 
 You own the *recurring opted-in publication and its open/click/growth system*. The plumbing under every send and the page that captures the signup are someone else's.
 
@@ -81,7 +71,7 @@ The subject and the preview (preheader) ship together and are tested together
 - **Payload in the first ~33 characters**; keep the whole subject ~30–50 chars (≈7–9 words) so it survives mobile truncation.
 - **The preview extends the subject, it never repeats it.** Its first ~35–50 chars are prime real estate; waste them on a duplicate and you've burned the line.
 - **≤2 emojis, at the end, never an all-emoji subject** — an all-emoji subject is the one case that actually trips filters.
-- **The "spam trigger words" list is a myth.** "Free", "guarantee", a normal emoji — these do not sink you; authentication and sender reputation dominate deliverability. Police reputation, not vocabulary; the reputation/auth layer lives in `email-deliverability`.
+- **The "spam trigger words" list is a myth.** "Free", "guarantee", a normal emoji — these do not sink you; authentication and sender reputation dominate deliverability. Police reputation, not vocabulary; the reputation/auth layer lives in `../email-deliverability/SKILL.md`.
 
 ```text
 Bad (payload past char 33, preview repeats subject):
@@ -134,13 +124,13 @@ A newsletter is the canonical bulk marketing message, so the Gmail/Yahoo bulk-se
 - **RFC 8058 one-click unsubscribe** (`List-Unsubscribe` + `List-Unsubscribe-Post` headers) on every send, plus a **visible footer unsubscribe link.** Both, always.
 - **Keep the spam-complaint rate under 0.1%** and never let it reach 0.3%. This is why you sunset, not why you mail harder.
 
-The DNS / authentication side of those rules — SPF, DKIM, DMARC, the sending domain — is **not this skill**; that is `email-deliverability`. This skill applies the rules to the issue and the cadence.
+The DNS / authentication side of those rules — SPF, DKIM, DMARC, the sending domain — is **not this skill**; that is `../email-deliverability/SKILL.md`. This skill applies the rules to the issue and the cadence.
 
 ## A/B testing the right way
 
 - **Test exactly one element at a time** — subject vs subject, or preview vs preview. Change two and the winner is uninterpretable.
 - **Put preview text in the rotation**, not just the subject; it's half the inbox row and usually under-tested.
-- The statistical design — sample size, significance, minimum detectable effect — is `ab-testing`. This skill tells you *what* to test; that one tells you whether the result is real.
+- The statistical design — sample size, significance, minimum detectable effect — is `../ab-testing/SKILL.md`. This skill tells you *what* to test; that one tells you whether the result is real.
 
 ## Anti-patterns
 
@@ -151,7 +141,7 @@ The DNS / authentication side of those rules — SPF, DKIM, DMARC, the sending d
 | Preview text repeats the subject | Burns half the inbox row on a duplicate | Preview extends the subject with new info |
 | Mailing a decaying list harder | Complaints climb; reputation and inbox placement collapse | Sunset / re-permission the dormant tier |
 | All-emoji subject line | The one emoji case that actually trips filters | ≤2 emojis, at the end, around real words |
-| Policing "spam trigger words" | A myth; reputation/auth decide deliverability | Fix auth + reputation in `email-deliverability` |
+| Policing "spam trigger words" | A myth; reputation/auth decide deliverability | Fix auth + reputation in `../email-deliverability/SKILL.md` |
 | Buying a list / no double opt-in | Spam traps and complaints gate the whole sender | Double opt-in; grow with referral + lead magnet |
 | Testing two variables at once | Winner is uninterpretable | One variable; preview in the rotation |
 | Referral ask bolted on months later | Misses peak engagement | Put the ask inside the welcome sequence |

package/skills/newsletter/references/growth-loops.md

@@ -23,7 +23,7 @@ tiering. Numbers below are dated; treat them as calibration, not promises.
   generic "join our newsletter."
 - The asset doubles as shareable bait for the referral loop — make it good
   enough to forward.
-- The opt-in *page* and its copy are `../landing-copy/SKILL.md`; this skill owns
+- The opt-in *page* and its copy are `../../landing-copy/SKILL.md`; this skill owns
   what the incentive is and how it ties into the welcome + referral flow.
 
 ## Opt-in: single vs double
@@ -64,10 +64,10 @@ this? click to stay") and, if no click, a **sunset** off the active list.
   is the lever that protects it. (Yahoo Sender Hub best practices; Google
   Workspace sender guidelines — accessed 2026-06-02.)
 - Re-permission is a newsletter-list hygiene step. Lifecycle reactivation of
-  lapsed *paying customers* is a different job — that is `retention`.
+  lapsed *paying customers* is a different job — that is `../../retention/SKILL.md`.
 
 ## Send-time hypothesis
 
 Tuesday/Thursday ~10am or 1–3pm is the cross-industry baseline starting point.
 It is a hypothesis to test against your own list's click data, never a fixed law.
-The test design (sample size, significance) is `ab-testing`.
+The test design (sample size, significance) is `../../ab-testing/SKILL.md`.

package/skills/notion-connector/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: notion-connector
-description: "Use when wiring an app, cron job, or service to Notion as an ops backend over the official HTTP API — pushing rows into a Notion database, mirroring a database into your app, syncing both ways without duplicates, building or reading page block content, or fixing an integration that broke after the 2025-09-03 data-source split. Triggers: 'store our tasks in a Notion database from code', 'use Notion as a CRM/content calendar', 'sync our CRM into Notion nightly without duplicates', 'why does POST /v1/databases/:id/query return 404 now', 'integration broke after a teammate added a second data source', 'guardar registros en una base de datos de Notion desde código', 'desar files a una base de dades de Notion'. NOT a generic call-any-REST-API integration (that is api-connector-builder), NOT receiving/verifying inbound Notion webhook events (that is webhooks)."
+description: "Use when wiring server code or a cron job to Notion as an ops backend over its HTTP API: pushing or mirroring database rows, two-way sync without duplicates, page blocks, or an integration broken by the 2025-09-03 data-source split. NOT generic REST wiring (that is `api-connector-builder`), NOT inbound Notion webhook events (that is `webhooks`)."
 tags: [notion, ops-backend, api-integration, databases, sync]
 recommends: [api-connector-builder, webhooks, automation-flows, spreadsheet-ops, secure-coding]
 origin: risco
@@ -14,24 +14,7 @@ write page blocks. This skill owns the **outbound** Notion API surface only —
 the database/data-source data model, property-type write shapes, and the
 rate-limit/pagination discipline that the API forces on you.
 
-## The one rule
-
-**Pin the `Notion-Version` per request, and resolve the data source before you
-query.** Post `2025-09-03` a database is a *container* of one or more data
-sources — not a queryable table. Skip either half and you get silent 404s on
-code that worked last year.
-
-- Current major version: **`2025-09-03`** (the SDK default). Latest: **`2026-03-11`**.
-- Behavior differs across versions; an unpinned client drifts when the default moves.
-
-## When to use / when NOT to use
-
-**Use when:** treating a Notion database as a CRM / task tracker / content
-calendar from code; pushing or pulling rows on a schedule; two-way sync that
-must not duplicate on re-run; building or reading page block content; migrating
-a `2022-06-28` integration that broke when someone added a second data source.
-
-**Route elsewhere:**
+## Route elsewhere
 
 | Situation | Route to |
 |---|---|
@@ -50,10 +33,12 @@ a `2022-06-28` integration that broke when someone added a second data source.
 3. **Share the target database/page with the integration** in the Notion UI
    (the page `•••` menu → Connections). *Skip this and every call 404s or
    returns empty* — the integration sees nothing it was not explicitly granted.
-4. **Construct the SDK client with a pinned version.** Official JS SDK is
-   `@notionhq/client` v5.12.0+ (latest 5.22.0, 2026-05-19); its default
-   `notionVersion` is `2025-09-03`, and it supports `2026-03-11` if you opt in.
-   The default and method names below are stable across the whole 5.x line.
+4. **Construct the SDK client with a pinned `Notion-Version`.** Official JS SDK
+   is `@notionhq/client` v5.12.0+ (latest 5.22.0, 2026-05-19); its default
+   `notionVersion` is the current major **`2025-09-03`**, and it supports the
+   latest **`2026-03-11`** if you opt in. The default and method names below are
+   stable across the whole 5.x line. Behavior differs across versions, so pin it
+   per client (or per request) — an unpinned client drifts when the default moves.
 
 ```ts
 import { Client } from "@notionhq/client"; // v5.12.0+ (latest 5.22.0)
@@ -66,9 +51,11 @@ const notion = new Client({
 
 ## The database → data source model (biggest gotcha)
 
-A database now holds a `data_sources` array; each data source has its **own
-schema**. One database can have several. You query and read schema against the
-*data source*, not the database.
+Post `2025-09-03` a database is a **container** of one or more data sources, not
+a queryable table: it holds a `data_sources` array and each data source has its
+**own schema**. Resolve the data source *before* you query — query and read
+schema against it, not against the database, or code that worked last year 404s
+silently.
 
 | You have… | Do this |
 |---|---|

package/skills/planetscale/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: planetscale
-description: "Use when operating PlanetScale serverless MySQL (Vitess) — setting up a database/branch and wiring the pscale CLI, shipping a schema change through branches and deploy requests, debugging a stuck/queued deploy or a cutover that won't finish, designing tables without foreign keys, or picking the serverless HTTP driver for an edge runtime. Triggers: 'schema change without downtime on PlanetScale', 'my migration is stuck in the deploy queue', 'the cutover hung', 'can I still revert 40 minutes after deploy', 'the 30-minute revert window', 'PlanetScale won't let me add a foreign key', 'relationMode prisma', 'MySQL connection times out on Vercel Edge', 'cambio de esquema sin downtime', 'no me deja usar foreign keys'. NOT raw MySQL query tuning, EXPLAIN, or index choice (that is postgresdb's MySQL-engine analogue / the mysql sibling), and NOT generic expand-contract migration theory (that is db-migrations)."
+description: "Use when operating PlanetScale (Vitess serverless MySQL) — branches and the `pscale` CLI, schema changes through deploy requests (Online DDL cutover, ~30-min revert window), tables without foreign keys, or the edge HTTP driver. NOT MySQL engine work like EXPLAIN or index choice (that is `mysql`), NOT generic migration theory (that is `db-migrations`)."
 tags: [planetscale, vitess, mysql, deploy-requests, serverless-db]
 recommends: [mysql, db-migrations, prisma-orm, drizzle-orm, github-actions, postgresdb]
 origin: risco
@@ -17,34 +17,15 @@ then **cuts over** with no table lock. Because Online DDL and sharding are the p
 gravity, you **design without foreign keys** (FKs are now an opt-in but unsharded-only feature). This
 skill owns that workflow — not MySQL the engine.
 
-## When to use / When NOT to use
+Heuristic for the boundary: **would this answer be identical on RDS MySQL? Then it is not this skill.**
 
-**When to use:**
-
-- Standing up a PlanetScale database, branch, or org and wiring the `pscale` CLI.
-- Shipping a schema change safely: dev branch → DDL → deploy request → diff → review → deploy → revert window.
-- A deploy request that is stuck/queued, a cutover that won't finish, or a lint error blocking deploy.
-- Designing relations when FKs are unavailable/discouraged: emulated relations, app-level integrity, ORM `relationMode`.
-- Choosing a connection path for edge/serverless (Cloudflare Workers, Vercel Edge, Lambda) where TCP MySQL is blocked.
-- Wiring deploy requests into CI (GitHub Actions) or a branch-per-PR preview database.
-
-**When NOT to use:**
-
-- A slow query, an `EXPLAIN` plan, an index decision, JSON columns, locking — that is MySQL-engine
-  work. The closest built sibling for engine-level relational guidance is `../postgresdb/SKILL.md`
-  (Postgres, but the engine-thinking transfers); pure MySQL tuning routes to the `mysql` sibling.
-  Heuristic: **would this answer be identical on RDS MySQL? Then it is not this skill.**
-- PostgreSQL engine/design — even PlanetScale's managed Postgres SQL semantics → `../postgresdb/SKILL.md`.
-  PlanetScale sells Postgres too, but this skill is strictly the **Vitess/MySQL branch+deploy-request** flow.
-- Engine-agnostic migration *theory* (expand-contract, backfill ordering) → the `db-migrations` sibling.
-  Here you get the concrete PlanetScale realization, not the theory.
-- Neon's Postgres copy-on-write branches → the `neon` sibling. Supabase's Postgres BaaS → `supabase`.
-- ORM client ergonomics (Prisma `updateMany`, Drizzle query builder) → `prisma-orm` / `../drizzle-orm/SKILL.md`.
-  This skill owns only the PlanetScale-specific knobs those ORMs expose (`relationMode`, serverless driver adapter).
-
-Deep dives: [deploy-requests](references/deploy-requests.md) (lifecycle states, queue/gating, lint
-errors, revert edge cases, declarative vs imperative) · [no-foreign-keys](references/no-foreign-keys.md)
-(emulated relations, ORM `relationMode`, the unsharded FK opt-in, Bad→Good schemas).
+| When the question is really about | Route to |
+| --- | --- |
+| A slow query, an `EXPLAIN` plan, an index decision, JSON columns, locking | `../mysql/SKILL.md` for MySQL-engine work; `../postgresdb/SKILL.md` when you want the transferable engine reasoning |
+| PostgreSQL engine/design — even PlanetScale's own managed Postgres SQL semantics | `../postgresdb/SKILL.md`. PlanetScale sells Postgres too; this skill is strictly the **Vitess/MySQL branch+deploy-request** flow |
+| Engine-agnostic migration *theory* (expand-contract, backfill ordering) | `../db-migrations/SKILL.md`. Here you get the concrete PlanetScale realization, not the theory |
+| Postgres copy-on-write branches | `../neon/SKILL.md`. Postgres BaaS → `../supabase/SKILL.md` |
+| ORM client ergonomics (Prisma `updateMany`, Drizzle query builder) | `../prisma-orm/SKILL.md` / `../drizzle-orm/SKILL.md`. This skill owns only the PlanetScale-specific knobs those ORMs expose (`relationMode`, serverless driver adapter) |
 
 ## Mental model
 
@@ -149,9 +130,14 @@ datasource db {
 ```
 
 With Drizzle, model the relation in app code (`relations()`), index the join column, and skip the
-`references()`-backed FK constraint at the DB layer. The opt-in unsharded FK is acceptable only when
-you are certain the table will never shard and you accept the Online DDL friction — see
-[no-foreign-keys](references/no-foreign-keys.md) for emulated cascades, ORM specifics, and the opt-in caveats.
+`references()`-backed FK constraint at the DB layer.
+
+| Will this table shard? | FK strategy | Notes |
+| --- | --- | --- |
+| Yes, or unsure | No DB FK — emulate in app/ORM | Default. Index the relation column; cascade in code. |
+| Never (small, bounded, unsharded) | Unsharded FK opt-in *is* acceptable | Accept Online DDL friction; document why it won't shard. |
+
+See [no-foreign-keys](references/no-foreign-keys.md) for emulated cascades, ORM specifics, and the opt-in caveats.
 
 ## Connecting
 
@@ -196,7 +182,7 @@ installs `pscale`, authenticates with a service token (`PLANETSCALE_SERVICE_TOKE
 
 For a **branch-per-PR preview database**, create a PlanetScale branch named after the PR head, run the
 app's migrations against it, and tear the branch down when the PR closes. The orchestration (matrix,
-secrets, cleanup-on-close) is generic CI — defer the Actions plumbing to the `github-actions` sibling
+secrets, cleanup-on-close) is generic CI — defer the Actions plumbing to `../github-actions/SKILL.md`
 and keep the PlanetScale verbs here.
 
 ## Anti-patterns
@@ -210,14 +196,3 @@ and keep the PlanetScale verbs here.
 | Treating revert as available forever | The window is **~30 min** and excludes dropped tables/cols and FK changes | Plan rollbacks as new forward deploys |
 | Deploying without reading `deploy-request diff` | You ship DDL you never saw; surprise table rewrites | Always run the diff before `deploy` |
 | Inventing a driver name (`@planetscale/serverless`, `planetscale-js`) | There is no such package; install fails | The package is exactly `@planetscale/database` |
-
-## Decision: FK strategy by sharding posture
-
-| Will this table shard? | FK strategy | Notes |
-| --- | --- | --- |
-| Yes, or unsure | No DB FK — emulate in app/ORM | Default. Index the relation column; cascade in code. |
-| Never (small, bounded, unsharded) | Unsharded FK opt-in *is* acceptable | Accept Online DDL friction; document why it won't shard. |
-
-When the question is really about reading a plan, picking an index, or query latency, that is engine
-work — route to the `mysql` sibling (or `../postgresdb/SKILL.md` for the transferable engine
-reasoning). This skill stops at the Vitess platform boundary.

package/skills/planetscale/references/no-foreign-keys.md

@@ -58,13 +58,13 @@ model Order {
 }
 ```
 
-ORM-client ergonomics beyond this knob belong to the `prisma-orm` sibling, not here.
+ORM-client ergonomics beyond this knob belong to `../../prisma-orm/SKILL.md`, not here.
 
 ## Drizzle: app-level relations
 
 Drizzle models relations in app code via `relations()` and queries them with the relational API. On
 PlanetScale you index the join column and skip the `references()`-backed DB constraint; the relation
-lives in code, not in the database. The query-builder side is the `../drizzle-orm/SKILL.md` sibling.
+lives in code, not in the database. The query-builder side is `../../drizzle-orm/SKILL.md`.
 
 ## The unsharded FK opt-in
 

package/skills/prompt-engineering/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: prompt-engineering
-description: "Use when one prompt has to give the same right answer across reruns, models, and hostile inputs — a prompt that works sometimes, forcing valid JSON or a fixed schema out of a model, choosing how many few-shot examples and which ones, hardening a prompt against injected instructions, writing a tiny eval set before changing a prompt, or porting a prompt to a new model without behavior drift. Triggers: 'the prompt works sometimes', 'force valid JSON from the model', 'how many few-shot examples', 'outputs drift between reruns', 'the model ignores my instructions on long inputs', 'users can paste instructions into my input field', 'el prompt a veces falla', 'forzar JSON válido del modelo', 'el model no segueix les instruccions'. NOT the agent loop, tool wiring, or RAG retrieval (that is building-agents)."
+description: "Use when one prompt must give the same right answer across reruns, models, and pasted-in hostile input: forcing a fixed schema, picking the few-shot set, ordering the prompt blocks, or the inline cases you run while tuning. NOT the agent loop, tools, or retrieval (that is `building-agents`), NOT a standing CI eval harness (that is `agent-eval`)."
 tags: [prompts, llm, few-shot, structured-output, evals]
 recommends: [building-agents, agent-eval, structured-extraction]
 origin: risco
@@ -10,12 +10,6 @@ origin: risco
 
 You are tuning a single prompt so it produces the same correct output across reruns, across models, and against adversarial input. This is the craft layer — the prompt artifact itself: its block order, its few-shot set, its output contract, and the small eval that proves it. The systems layer (loop, tools, retrieval) is `../building-agents/SKILL.md`.
 
-## The one rule
-
-> A prompt is not done until it passes a small eval set you wrote **before** you started tuning. Without cases you are fiddling — changing words and trusting a vibe. With 5-15 cases, every edit is a measurement.
-
-Write the cases first. They define "right answer" before you fall in love with a phrasing.
-
 ## Prompt skeleton (this order)
 
 Order the blocks so the model reads identity and task before it sees the (untrusted) input. Each block earns its place:
@@ -86,11 +80,11 @@ Good (range: normal / awkward / edge):
 - **Re-state the task after the input** for long inputs. Why: when the input is huge, early instructions fall out of attention — this is the cause of "the model ignores my instructions on long inputs".
 - **Phrase constraints positively.** "Output only the category" survives; "don't add commentary" invites the model to negotiate.
 - **Add a refusal anchor** — one explicit branch for out-of-contract input (`If the ticket is empty or unreadable, output: other`). Why: undefined behavior is where injections and drift live.
-- System-scope abuse handling — refusal policy, monitoring, jailbreak defense across a product — is `agent-safety`, not this skill. Here you harden one prompt.
+- System-scope abuse handling — refusal policy, monitoring, jailbreak defense across a product — is `../agent-safety/SKILL.md`, not this skill. Here you harden one prompt.
 
-## Inline evals (the part people skip)
+## Inline evals — write these first
 
-Build 5-15 cases next to the prompt and run them before AND after every change.
+A prompt is not done until it passes a small eval set you wrote **before** you started tuning: 5-15 cases next to the prompt, run before AND after every change. Cases fix what "right answer" means before you fall in love with a phrasing — without them you are fiddling, changing words and trusting a vibe; with them every edit is a measurement.
 
 ```yaml
 # prompt-eval cases for the triage prompt
@@ -112,7 +106,7 @@ cases:
     expect: { equals: "billing" }   # input treated as data, not command
 ```
 
-Assert on the contract: schema-valid, exact token, contains/not-contains. Keep them in the repo beside the prompt. The standing harness — golden set, LLM-as-judge, CI regression gate, metrics — is `agent-eval`; this is the small inline set you run while tuning.
+Assert on the contract: schema-valid, exact token, contains/not-contains. Keep them in the repo beside the prompt; `references/eval-templates.md` has the cases.yaml shape, assertion helpers, and a before/after diff runner. The standing harness — golden set, LLM-as-judge, CI regression gate, metrics — is `../agent-eval/SKILL.md`; this is the small inline set you run while tuning.
 
 ## Iterate one variable at a time
 
@@ -131,8 +125,3 @@ Assert on the contract: schema-valid, exact token, contains/not-contains. Keep t
 | 3 near-identical few-shot examples | Teaches one shape, wastes tokens | 3 deliberately different: normal / awkward / edge |
 | Negative-only constraints ("don't…") | Invites negotiation, ignored on long input | Phrase positively; re-state task after long input |
 | Tuning by vibe, no cases | You are fiddling, not engineering | Write 5-15 cases first; measure each edit |
-
-## References
-
-- `references/output-contracts.md` — per-provider strict-output recipes, schema surface (pydantic/zod), streaming caveat, retry-on-parse-fail loop.
-- `references/eval-templates.md` — cases.yaml shape, assertion helpers, before/after diff runner, DSPy MIPROv2-vs-GEPA when-to-optimize note.

package/skills/prompt-engineering/evals/cases.yaml

@@ -10,7 +10,7 @@ should_trigger:
   - prompt: "Make this prompt enforce a fixed schema reliably instead of sometimes returning prose."
     why: "Forcing a fixed schema out of a model — the output-contract decision table (strict json_schema / strict tool use vs JSON mode)."
   - prompt: "Write me a small eval set to check this prompt before I change it."
-    why: "Inline eval set authored before tuning — 'the one rule' of the skill; the small set, not a standing harness."
+    why: "Inline eval set authored before tuning — the discipline the 'Inline evals — write these first' section exists to enforce; the small set, not a standing harness."
   - prompt: "Users can paste 'ignore your instructions' into my input field and the model obeys it."
     why: "Prompt-scope injection hardening — delimiting untrusted input and treating it as data, a named robustness rule."
   - prompt: "I'm moving this prompt from one model to another and the behavior shifted; how do I keep it stable?"