Conventional commits, branching, SemVer, changelog. Trigger: writing a commit, naming a branch, cutting a release.
type(scope): subjectBREAKING CHANGE: footer for backward-incompatible changesFixes #123The detail lives beside this file so the rules above stay readable. Each pointer says when to open it:
BREAKING CHANGE
footer shape.Version bumps follow SemVer, derived from the commits since the last tag: a
BREAKING CHANGE footer bumps major, feat bumps minor, fix bumps patch.
That mapping is the reason the type matters — a commit typed wrong silently
produces the wrong release.
CHANGELOG.md follows Keep a Changelog: group entries under Added, Changed,
Fixed, Removed, and Deprecated, newest version first, and write for someone
upgrading rather than for someone reading the diff.
The conventions above are the default; a repository may enforce its own. Before
committing into an unfamiliar repo, check what is actually configured —
lefthook.yml or .husky/ for hooks, commitlint* for accepted types, and
git log --oneline -20 for the scopes the project really uses. Match the repo
you are in over this skill.
One logical change per commit, and every commit passes the suite on its own — a commit that only builds together with the next one cannot be reverted or bisected, which is what commit history is for.
Explain what changed and why in the body; the diff already shows how. Reference
the issue (Fixes #123) so the context survives after everyone involved has
forgotten it.
assets/scripts/commit.sh - Commit automation scriptassets/scripts/release.sh - Release automation scriptYoizenSA/dev-ai-workflow
36f5af5
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.