Stats
Actions
Tags
From dev-toolkit
Use when you need to understand or enforce the project's git conventions — commit message format, branch naming, or the branching/release flow.
How this skill is triggered — by the user, by Claude, or both
Slash command
/dev-toolkit:git-conventionsThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
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.
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).
npx claudepluginhub aeriondyseti/aeriondyseti-plugins --plugin dev-toolkitGuides teams in choosing a branching strategy (trunk-based, GitHub Flow, Git Flow, GitLab Flow), defining commit conventions (Conventional Commits), setting up PR workflows, managing releases, and establishing git standards.
Provides Git workflow standards including branch naming, conventional commits, and PR guidelines. Use when creating branches, writing commits, or preparing PRs.
Applies Conventional Commits v1.0.0 standards for Git branch naming, worktree organization under .claude/worktrees/, and commit messages in GitHub/GitLab projects. Supports consistent history, SemVer releases, and changelog automation.