# Evals — performance

These cases are routing and trigger fixtures, not an automated test harness. `should_trigger` lists prompts the `performance` description and body must claim — including the non-obvious ones (whole-library import, a `'use client'` boundary shipping the server tree) and the Catalan/Spanish phrasings. `should_not_trigger` lists near-miss prompts that belong to a real sibling, each tagged with the `route_to` id it should defer to (`scaling`, `postgresdb`, `redis`, `nextjs`, `react`). `capability` is one "slow product page" scenario with a `must_include` rubric covering the measure → attribute → fix → re-measure loop. To run them, read each prompt against `../SKILL.md` and confirm by hand that the triggers fire, the non-triggers route to the named sibling rather than being grabbed, and a real answer to the capability scenario hits every rubric line — or feed this file to the repo's eval runner if one is present. The committed performance budget the skill tells you to author is checked separately by `../scripts/verify.sh`.
