git-commit

name	git-commit
description	You MUST use this for commit-message requests and committing staged changes. Generate, improve, or apply Conventional Commit messages using staged changes and repository history.
license	Apache-2.0
metadata	{"author":"Oleg Shulyakov","version":"1.0.0","source":"github.com/olegshulyakov/agent.md","catalog":"utility","category":"version-control","tags":["git","commit"]}

Git Commit

Generate commit messages in the Conventional Commits format. Use the target repository's recent Git history to refine scope, capitalization, body usage, and footer conventions without abandoning the Conventional Commits structure.

Before generating a message, inspect the relevant diff and recent commit subjects.

---

Workflow

1. Classify the request as an output or action workflow.
2. Inspect the relevant diff and recent commit subjects.
3. Generate or review the message using the conventions below.
4. Return only the commit message for pure generation requests.
5. Commit only staged changes when the user requests an action.

Output Workflow

Use when the user asks to generate, draft, improve, format, or review a commit message. For pure generation requests, return only the message unless the user asks for explanation. Reviews may include concise, actionable feedback.

Action Workflow

Use when the user asks to commit staged changes.

• Inspect the current branch, worktree, and staged diff first.
• Do not stage files unless the user explicitly asks.
• If nothing is staged, ask whether to stage files or provide a message only.
• Preserve the selected message exactly when running git commit.
• Report the command outcome or any blocker that prevents completion.

---

Format

<type>(<optional scope>): <short description>

<optional body>

<optional footer>

Rules

• First line (header): match recent repository subjects; keep it concise; no trailing period.
• Blank line separates header from body and body from footer.
• Body: omit for simple changes. Include only when the change has several meaningful parts or the motivation would otherwise be unclear.
• Body bullets: when needed, use - bullets and describe what changed and why.
• Footer: reserved for metadata such as breaking changes or issue references.

---

Repository Style

Infer local preferences from recent commit subjects in the target repository:

• Scoped format: Use type(scope): summary when the repository commonly uses scopes and there is a clear package, folder, domain, component, or feature area.
• Unscoped format: Use type: summary when the change is broad or no scope is clearer.
• Scope choice: Prefer scopes already present in history when they fit. If no local scope pattern exists, derive a short noun from the changed area, such as the package, module, app, command, or documentation section.
• Capitalization: Match the repository's capitalization style after the colon. If history is mixed or unclear, default to lowercase imperative text and preserve proper nouns, acronyms, tool names, and file names.
• Known identifiers: Include PR, issue, or ticket suffixes only when they are already known from the user's context, branch name, staged diff, or command output. Do not invent identifiers.
• Literal quoting: Preserve quoting style around literal file names, directories, commands, API names, config keys, or package names when that matches the repository or improves clarity.
• Simple commits: For simple commits, return a single-line message unless the repository consistently uses bodies.
• Multi-part commits: For squash-style or multi-part commits, use a concise header followed by bullets. Do not copy GitHub merge bullet prefixes such as * feat(...) into newly generated messages.

Do not imitate obvious historical mistakes such as misspelled types, malformed headers, duplicate prefixes, or accidental copied bullet text. Treat those as evidence that the generator needs guardrails, not as precedent. A little mercy for past commits; none for new ones.

Types

Type	When to use
feat	A new feature
fix	A bug fix
docs	Documentation changes only
style	Formatting, whitespace — no logic change
refactor	Code restructure with no feature/fix
perf	Performance improvement
test	Adding or updating tests
build	Build system or dependency changes
ci	CI/CD configuration changes
chore	Maintenance tasks (e.g. updating scripts)
revert	Reverts a previous commit

Use only these type names. Convert feature to feat, and fix obvious type typos.

---

Action Words

Treat these user words as commit action intent:

User wording	Git behavior
commit this	Commit staged changes only
commit the staged changes	Commit staged changes only
create a commit	Commit staged changes only
create a commit message and commit	Generate the message, then commit staged changes
write a commit message	Output a message only, unless commit is requested

Before committing, inspect staged changes. If nothing is staged, ask whether to stage files or only provide a message. Do not stage files by default.

Scope (optional)

A short noun in parentheses that clarifies which part of the codebase the change affects.

Prefer scopes from recent history when applicable. If the repository has no clear scope convention, use a short noun from the changed path or omit the scope.

Short Description

• Imperative mood: Use "add feature" not "adds feature" or "added feature".
• Lowercase start: Use a lowercase first letter unless the first word is a proper noun or acronym.
• No trailing period: End the header without punctuation.
• Compact header: If the header becomes hard to read, use a body instead of cramming.

Body (optional)

Include when the change is non-obvious, complex, or has multiple independently useful points. Use bullets:

- Describe motivation or background
- Explain key decisions made
- Note anything reviewers should pay attention to

Avoid a body that merely restates the header.

Footer (optional)

Breaking Changes

Use a BREAKING CHANGE: footer when the staged change introduces an incompatible API, behavior, config, data, CLI, or migration change. Keep the prefix exactly uppercase:

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

Issue References

Closes #123
Fixes #456
Refs #789

---

Examples

Simple Change

fix(auth): prevent expired sessions from refreshing

Multi-Part Change

refactor(skills): split Git workflow guidance

- Move branch operations into a focused skill
- Move commit-message guidance into a separate skill

Breaking Change

feat(api): require scoped access tokens

BREAKING CHANGE: Existing unscoped tokens must be replaced before upgrading.

---

Verification

• The message describes the inspected diff and follows Conventional Commits.
• Repository history informs style without reproducing malformed precedent.
• Action workflows commit only the intended staged changes.