Menu
Use when designing or reviewing specifications to follow constraints-examples-specs traceability model
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
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 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.
| name | constraints-examples-specs-approach |
| description | Use when designing or reviewing specifications to follow constraints-examples-specs traceability model |
SINGLE_OWNER: every data value has exactly one authoritative source that consumers import — otherwise a second copy drifts and no reader knows which is canonical LAYER_SEPARATION: constraints own boundaries, examples own composition, specs own assertions — otherwise a boundary change ripples into files that should not care CHAIN_INTEGRITY: every value traces constraint → example → spec unbroken — otherwise a mid-chain literal is an orphan that no requirement backs and no boundary governs OUTCOME_TITLES: a spec title states the business requirement, not the mechanics — otherwise the requirement of record is vague and the assertion is untraceable
CONSTRAINTS: boundary values, defaults, system constants in cypress/constants/
EXAMPLES: executable named instances composed from constraints in cypress/integration-examples/, cypress/e2e-examples/
SPECS: requirement titles plus assertions in cypress/integration/, cypress/e2e/
DIRECTION: constraint value → example field → spec title → assertion
BOUNDARY_TO_EXAMPLE: examples import constraint constants and compose fields from them
EXAMPLE_TO_SPEC: specs import examples and reference instances directly
SPEC_TO_ASSERTION: it title names the business outcome; assertion verifies an example value or a constraint boundary
REQUIREMENT_TO_LAYERS: one business requirement → constraint boundary + example instance + spec assertion
BOUNDARY_SPLIT: one constraint file per domain concept
INSTANCE_SPLIT: one example key per distinct tested state
SPEC_SPLIT: one it per verified outcome; related property checks on the same element allowed
MULTI_MODULE: each module keeps its own constraints and examples; a spec imports from all — colocating another module's data would give it two owners
API_UI_DIVERGENCE: examples mirror the API field name; specs use l10n for UI text — the API name is the data's identity, the UI string is presentation
CONSTRAINT_OVERLAP: a boundary enforced across multiple modules or pages → a domain-tier file (domain-name.api.constraints.js or domain-name.ui.constraints.js) named after the domain concept, never after a consumer, so no consumer owns shared truth
EXAMPLE_COUPLING: a spec creates its own instance via an API command; never import another spec's examples — cross-spec imports couple unrelated files and break isolation
BROKEN_CHAIN_SIGNAL: a literal in a spec that could trace to a constraint → extract it to its owning layer
CONSTRAINTS_SKILL: define-constraints for boundary authoring
EXAMPLES_SKILL: define-examples for instance composition
SPEC_SKILLS: write-integration-api-specs, write-integration-ui-specs, write-e2e-ui-specs
TRACE_CHECK: constraint → example field → spec title → assertion resolves end to end PLACEMENT_CHECK: no boundary literal in examples, no payload reconstruction in specs SINGLE_OWNER_CHECK: no duplicated definitions across layers CHAIN_COMPLETENESS: every constraint consumed by an example, every example consumed by a spec
