원클릭으로
git-strategy
Use when creating branches, writing commits, or opening pull requests in this repository.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
Use when creating branches, writing commits, or opening pull requests in this repository.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
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
| 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