Commit Message Validation

Strict Conventional Commits v1.0.0, atomic commit discipline, and Trunk-Based Development guardrails for git work. Use when preparing a commit, staging chang...

Security Scan

The skill's files, instructions, and requirements are coherent with a commit-message validation tool; it has no network calls, no secret requests, and no surprising install steps.

Purpose & Capability

The name/description advertise Conventional Commits enforcement and trunk-based guardrails; the repository includes a validator script, a commit-msg hook that runs the validator, and tests — all consistent with that purpose.

Instruction Scope

SKILL.md instructs the agent to run simple git checks and to validate messages with scripts/validate_commit_message.py. The validator only reads the supplied commit message (argument, file, or stdin) and doesn't access other system files, environment variables, or external endpoints.

Install Mechanism

There is no automated install spec (instruction-only). Hook installation is manual (copy into .git/hooks). No downloads, package installs, or remote code fetches are present.

Credentials

The skill requires no environment variables, credentials, or config paths. The code does not reference secrets or unrelated environment state.

Persistence & Privilege

always is false and the skill does not request persistent system privileges. Installing the commit hook is an explicit manual action by the user and the hook only runs the local validator script if present.

Assessment

This skill appears to do exactly what it says: validate commit messages locally. There are no network calls or credential requests. If you plan to use it, manually copy scripts/commit-msg-hook.sh into .git/hooks/commit-msg and ensure the validator path resolution matches your repo layout (the hook searches a few relative paths for scripts/validate_commit_message.py). Note the hook will skip validation if it can't find the validator (prints a warning) and the validator will block commits by returning non-zero on invalid messages. You may want to run the bundled tests (tests/test_validate_commit_message.py) or inspect validate_commit_message.py to confirm the exact rules match your team's policy before enabling the hook.

Commit Message Writing

Every commit: valid Conventional Commit, atomic, on the right short-lived branch.

Required workflow

1. git status --short and git diff --stat.
2. Verify you're on a short-lived branch dedicated to one feature, bug, fix, or coding area. If not, create/switch first.
3. Confirm the changes are one logical unit. If mixed, split before committing.
4. Confirm automated tests appropriate to the scope will run.
5. Pick the most specific commit type.
6. Write the message:

<type>[optional scope][!]: <imperative lowercase description>

[optional body]

[optional footer(s)]

7. Validate with scripts/validate_commit_message.py before committing.

Hard rules

• One short-lived branch per feature, bug, fix, or distinct coding area.
• Keep branches narrow, merge back quickly, avoid long-lived divergence.
• Every PR must have robust automated tests so bugs are caught early.
• Always include a lowercase type followed by : .
• Imperative, lowercase description, no trailing period, ≤72 chars.
• Body: one blank line after description. Footers: one blank line after body.
• Footer format: Token: value. Hyphens in tokens except BREAKING CHANGE.
• Use ! and/or BREAKING CHANGE: footer for breaking changes.
• Never use WIP, misc, update, or vague summaries.

Types

Type	When	SemVer
feat	new feature	minor
fix	bug fix	patch
refactor	restructure, no behavior change	none
perf	performance improvement	none (patch if fixes bug)
docs	documentation only	none
test	tests only	none
build	build system / deps	none
ci	CI/CD changes	none
chore	maintenance / tooling	none
style	formatting only	none
revert	revert prior commit	depends

Scope

Use a consistent noun for the dominant area. Omit only when truly cross-cutting. Never multiple scopes in one commit line.

Splitting rules

Split when:

• feature + bug fix
• code + formatting-only cleanup
• deps/build + application logic
• refactor + standalone behavior change
• generated files + loosely coupled source

One type, one intent per commit. If you can't describe it that way, split.

Validation

python3 scripts/validate_commit_message.py --message "feat(auth): add otp fallback"