Menu
Use when you need to understand or enforce the project's git conventions — commit message format, branch naming, or the branching/release flow.
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 before any code change — new feature, bug fix, refactor, or tech debt. Explores the problem, builds understanding through concrete artifacts, and produces a spec that gates the transition to execution.
Use when you have an approved spec from the Discover phase. Orchestrates implementation — parallel or serial — with autonomy and guardrails.
Use at the start of every conversation and when deciding how to approach a task. Routes to the appropriate phase of the Discover → Execute → Verify flow.
Use after execution is complete, before declaring work ready to ship. Unified verification through multiple lenses: correctness, code quality, review, and architectural feel.
Use when creating, switching, syncing, or cleaning up git branches. Enforces naming conventions and the branching flow.
Use at the start of a new conversation or when working in an unfamiliar codebase. Generates a ranked map of the repository structure to orient before diving into code.
| name | git-conventions |
| description | Use when you need to understand or enforce the project's git conventions — commit message format, branch naming, or the branching/release flow. |
This skill defines the git conventions to follow in projects that use a trunk-based development model with release candidates. Apply these conventions whenever creating commits, branches, or pull requests.
Follow Conventional Commits. Every commit message has the structure:
<type>[optional scope][optional !]: <description>
| Type | When to use | Semver impact |
|---|---|---|
feat | A new feature or capability | MINOR |
fix | A bug fix | PATCH |
chore | Version bumps, dependency updates, config changes, cleanup | None |
refactor | Code restructuring without behavior change | None |
docs | Documentation only | None |
test | Adding or updating tests | None |
perf | Performance improvement | None |
ci | CI/CD workflow changes | None |
Append ! after the type (or scope) to signal a breaking change. This triggers a MAJOR semver bump.
feat!: restructure repo into server/ and plugin/ with --plugin mode
fix(config)!: rename --output flag to --dest
add user auth, not Added user auth.fix(parser): handle empty inputfeat: add vector search endpoint
fix: run context monitor on PostToolUse for autonomous sessions
chore: bump version to 2.3.0-rc.2
refactor: extract embedding logic into shared module
docs: update release checklist with test results
test: add integration tests for memory consolidation
| Branch type | Pattern | Example |
|---|---|---|
| Feature | feat/<kebab-case-description> | feat/auto-migrate-startup |
| Bug fix | fix/<kebab-case-description> | fix/context-monitor-timing |
| Release candidate | rc/<semver> | rc/2.3.0 |
| Integration | dev | dev |
| Stable | main | main |
dev for features and fixesmain ← (PR) ← rc/X.Y.Z ← (cherry-picks/fixes) ← dev ← feat/* / fix/*
dev, do work, merge back into devdev branch — integration/dogfooding. Unprotected, open for direct pushes. Publishes @dev npm tag on push.rc/X.Y.Z branches — cut from dev when ready to stabilize. Only bug fixes and chores allowed (no new features). Publishes @rc npm tag on push.main branch — protected. Changes arrive only via PR from rc/X.Y.Z (or dev for simpler projects). Publishes @latest npm tag, creates git tag and GitHub Release.dev is reset/merged to match main, RC branch is deleted.Some projects skip the RC step:
main ← (PR) ← dev ← feat/* / fix/*
In this model, dev publishes @dev and PRs from dev to main publish @latest.
main — test status check required before merge. PRs require reviews from CodeRabbit and/or Copilot.dev — unprotected, direct pushes allowedrc/* — unprotected, but only fixes/chores should land hereWhen determining a version bump, analyze commits since the last tag:
feat!: or fix!: → MAJORfeat: → MINORfix:, chore:, refactor:, docs:, test:, perf:, ci: → PATCHThe highest-impact commit wins (MAJOR > MINOR > PATCH).