Menü
Use when creating branches, writing commits, or opening pull requests in this repository.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
| name | git-strategy |
| description | Use when creating branches, writing commits, or opening pull requests in this repository. |
LINEAR_HISTORY: squash merge only, one commit per change — otherwise merge and rebase commits fracture main so it no longer bisects and a ticket no longer maps to a single revision
ATOMICITY: one logical change per commit — otherwise a mixed commit cannot be reverted or reviewed without collateral
INTENT_OVER_ACTION: commit body explains why, not what — otherwise the reasoning is lost while the diff still shows what, and the part that decays goes unrecorded
TRACEABILITY: ticket key threads branch, commit scope, and PR title — otherwise a change with no ticket link strands its context
SYNC: git checkout main && git pull before branching, so the branch starts from current base
BASE_BRANCH: main
BRANCH_NAME: feature/<TICKET_KEY>-<short-kebab-description>
STYLE: Conventional Commits — <type>(<scope>): <imperative summary>
MOOD: imperative summary
SCOPE: optional, ticket key when helpful, e.g. feat(B52-1234): add cart link
BODY: optional, explain why
CHECKS: pre-commit checks pass before pushing → open PR against main
TITLE: mirrors the squash-commit message
REVIEW: one approval required
PR_UPDATES: follow-up commits push to the same branch
MERGE: squash and merge once approved
BRANCH_CHECK: branch name matches feature/<TICKET_KEY>-<short-kebab-description>
CHECKS_GATE: pre-commit checks pass before suggesting a PR
COMMIT_CHECK: each commit is a single logical change with a Conventional Commits summary
MERGE_CHECK: squash merge into main, no merge or rebase commits
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
