Introduction

In most projects a commit message is a note to a human: a short line someone might read later while hunting a regression. In Cogitave it is that and an instruction to the machine. The type you put in front of your message decides whether the next release is a patch, a minor, or a major version - and whether your change even appears in the changelog. Write the message carelessly and you version the code wrong.

The root AGENTS.md makes this rule 2 of the non-negotiable floor: every commit is Conventional Commits 1.0.0, <type>[scope][!]: <desc>. This module is where that one-line rule becomes a working skill. The single source of truth is the commits-versioning standard; the branching and release flow that carries a commit to a release lives in the branching-release standard. Learn the shape here, then follow those docs for the exact detail.

Why it is enforced, not suggested

Because the message drives an automated release, it cannot be optional. commitlint checks every message against the Conventional Commits grammar in two places - the local commit-msg hook and again in CI - so a malformed message is rejected before it can mislead the release engine. A convention a machine reads has to hold every time, or the version it produces is wrong.

What you will get from this module

Not a style guide - a working command of three things: how to write a commit whose type, scope, and breaking marker are chosen deliberately; how those commits drive Semantic Versioning and flow into a release-please Release-PR, changelog, and tag; and where a commit sits in the trunk-based, protected-main model that gates every release. After this, you can write commits that version and release the code correctly.