cypress-start

Use when logging a bug, classifying severity, referencing a bug in a spec, or reconciling a deviation between expected and actual behaviour — governs the bug entry schema, ID format, status lifecycle, AI-automated vs manual channels, and `req.bugs` spec integration.

Use when testing colour-themed UI elements or maintaining colour keys — asserting CSS colours through the typed `colours` map and keeping the flat dot-namespaced key convention consistent across theme files, generated types, specs, and commands. Triggers on new colour assertions, hardcoded RGB/hex values in specs, missing-key type errors, duplicate values, theme-switch assertions, or colour value changes.

Use when designing or reviewing specifications to follow constraints-examples-specs traceability model

Use when creating or updating compact, tag-based skill files in `.claude/skills/`.

Use when defining or changing any reusable test boundary — min/max lengths, ranges, formats, regex, enums, allowed/required fields, status codes, durations, timeouts, display options, or valid/invalid value sets. Triggers on new constraint files, editing any `*.constraints.js` file under `cypress/constants/`, a hardcoded boundary/enum/format literal appearing in a spec or example, "add a validation rule", "what are the valid values", boundary or edge-case values, or duplicated limits that need one owner.

Use when creating or updating example files that compose named test-data from constraints

Use when adding or updating a custom ESLint rule, hitting a `custom/*` lint error, suppressing a rule inline, or understanding what a project custom rule enforces and why.

Use when creating branches, writing commits, or opening pull requests in this repository.

Use when testing localized UI text or maintaining localization keys — asserting strings through the typed `l10n` map and keeping the flat dot-namespaced key convention consistent across locale files, generated types, specs, and commands. Triggers on new UI strings, hardcoded text in specs, missing-key type errors, duplicate values, wording changes, or language-switch assertions.

Use when designing or reviewing non-functional test approaches for performance, security, accessibility, and reliability concerns within Cypress specs.

Use when a commit is blocked by the git hook, the lint ratio fails against thresholds, deciding whether to bypass the hook with --no-verify, or understanding what auto-fix and auto-tighten do.

Use on to produce the leanest correct solution that removes accidental complexity, anti-features, and waste.

Use to validate a code solution or decision before accepting it — architectural fit and tactical soundness (correctness, efficiency, performance, error stability), for both design-level and local choices.

Use when creating or updating Cypress command files that encapsulate reusable multi-step flows, complex assertions, or shared setup and teardown.

Use when creating, updating, or pruning human-readable Markdown docs in `docs/` — keeps skills the source of truth for canonical rules and docs a thin orientation layer that points to them.

Use when writing, updating, or reviewing any end-to-end UI journey that spans multiple pages or steps (create → modify → verify → complete) — checkout, purchase, signup, or other multi-page user flows. Triggers on editing any `*.spec.js` under `cypress/e2e/`, adding a new e2e/journey test, a `describe`/`it` chaining several pages together, "test the whole flow / user journey", reusing an entity created earlier in the flow, or a workflow spec that must trace to constraints and named examples.

Use when writing, updating, or reviewing any API-level test — asserting responses, status codes, payloads, headers, or CRUD lifecycle behavior of an endpoint. Triggers on editing any `*.api.spec.js` under `cypress/integration/api/`, adding a request-based test (cy.request/api command), asserting an endpoint's contract or error case, create-update-delete against an API, or a spec whose asserted values must trace to constraints and named examples.

Use when writing, updating, or reviewing any single page or component UI test — asserting one page's visible behavior, elements, validation messages, or state after an action. Triggers on editing any `*.ui.spec.js` under `cypress/integration/ui/`, adding a page-level test (login, inventory, cart, etc.), asserting UI text/elements/errors, driving one page while seeding preconditions via API, or a spec whose asserted values must trace to constraints and named examples.