git-cmt-helper

Generate standardized git commit messages following Conventional Commits format. Use this skill when the user asks to commit code, write a commit message, or...

Security Scan

The skill's requested inputs and instructions match its stated purpose (generating Conventional Commits); it is an instruction-only helper with no installs, secrets, or unexpected endpoints.

Purpose & Capability

Name and description (generate Conventional Commits) match the SKILL.md content and the included modules list. The skill does not request unrelated binaries, credentials, or config paths.

Instruction Scope

SKILL.md is narrowly focused on commit message structure, scope selection, examples, and rules. It references a local modules.md for valid scopes and suggests checking file paths being changed, which is reasonable for choosing a scope; it does not instruct the agent to exfiltrate data or call external endpoints.

Install Mechanism

No install spec and no code files — instruction-only skills are the lowest disk-execution risk. Nothing is downloaded or written to disk by the skill itself.

Credentials

No environment variables, credentials, or config paths are requested. The constraints (valid scopes) are provided in the included references/modules.md file.

Persistence & Privilege

always is false and model invocation is allowed (platform default). The skill does not request persistent presence or modify other skills or system settings.

Assessment

This skill is an instruction-only commit-message formatter and appears coherent with its purpose. If you install it, ensure your agent already has appropriate repository access (read context/diffs) because the guide suggests checking changed file paths to choose scope. No secrets or external downloads are required. Review SKILL.md and references/modules.md if you want to confirm the enforced conventions before enabling the skill.

Git Commit Message Guide

Format

Every commit message MUST follow this structure:

<type>(<scope>): <subject>

[optional body]

[optional footer]

Type (required)

Type	When to use
feat	New feature or capability
fix	Bug fix
docs	Documentation only
refactor	Code change that neither fixes nor adds
test	Adding or updating tests
chore	Build, CI, tooling changes

Scope (required)

Scope MUST be a real module name from this project. See references/modules.md for the full list.

If unsure of the scope, check the file paths being changed — the top-level directory is usually the correct scope.

Subject (required)

• Imperative mood: "add feature" not "added feature"
• No period at the end
• Max 72 characters total (including type and scope prefix)
• Lowercase first letter

Body (optional)

• Explain WHY, not WHAT (the diff shows what changed)
• Wrap at 72 characters
• Separate from subject with blank line

Breaking Changes

If the commit introduces a breaking change, add footer:

BREAKING CHANGE: <description of what breaks and migration path>

Examples

Good:

feat(auth): add JWT token refresh endpoint

Tokens now auto-refresh 5 minutes before expiry.
Previously users had to re-login after token expiration.

fix(parser): handle empty input without crashing

refactor(db): extract connection pooling to separate module

BREAKING CHANGE: DatabaseClient constructor no longer accepts
pool config. Use PoolConfig.create() instead.

Bad:

updated some stuff          ← no type, no scope, vague
feat: Add new Feature.      ← capitalized, period, missing scope
fix(misc): various fixes    ← "misc" is not a real module