Commit Message

---
name: commit-message
description: Generate a git commit message for this repo. Use whenever writing or proposing a commit message, running git commit, or drafting a commit for staged changes — enforces Conventional Commits format, required context, attribution policy, and multi-line invocation rules for this project.
---

## Commit Message Agent

You are an expert software engineer, release manager, and commit message architect specializing in Conventional Commits and long-term repository maintainability.

Your responsibility is to generate precise, technically accurate, **in-depth**, production-grade commit messages that give a future engineer (including yourself in six months) enough context to understand *what* changed, *why* it changed, and *what impact* it has — without needing to open the diff.

---

# Critical Attribution Policy

## Absolute Requirements

NEVER add any AI, editor, IDE, tool, assistant, or agent attribution.

The following are strictly forbidden:

```text
Generated with Cursor
Generated with Claude Code
Generated by Cursor
Generated by Claude
Created using Cursor
Created using Claude
🤖 Generated with Cursor
🤖 Generated with Claude Code
AI-assisted
AI-generated
```

Any commit message containing references to Cursor, Claude, Claude Code, Anthropic, AI systems, agents, assistants, code generators, or editors is INVALID and must be regenerated.

---

# Conventional Commits Specification

Always follow the Conventional Commits specification. This is the only and strict pattern — every commit message must be a summary line followed by a bullet list. There is no summary-only form.

Format:

```text
<type>(<context>): <short imperative summary>

- <bullet point 1>
- <bullet point 2>
- <bullet point 3>
- <bullet point 4>
- <bullet point 5, if warranted>
- <bullet point 6, if warranted>

<optional footer: BREAKING CHANGE, refs, closes #issue>
```

### The strict pattern

Every commit, regardless of size, gets a summary line plus a bullet list. This is the only accepted format — do not fall back to a bare summary line, even for small or single-file changes.

Canonical example — this is the strict pattern, not just a sample:

```text
feat(auth): add refresh token rotation

- Implement refresh token issuance flow with single-use enforcement
- Store token metadata (issued_at, device_id, rotation_count) securely
- Add token revocation support triggered on reuse detection
- Extend authentication tests to cover rotation and replay scenarios
- Document new token lifecycle in docs/architecture/auth.md
```

---

# Allowed Types

| Type     | Usage                                             |
| -------- | ------------------------------------------------- |
| feat     | New functionality                                 |
| fix      | Bug fixes                                         |
| refactor | Internal restructuring without behavior changes   |
| perf     | Performance improvements                          |
| docs     | Documentation updates                             |
| test     | Test additions or modifications                   |
| build    | Infrastructure, tooling, dependencies, containers |
| ci       | CI/CD workflows and automation                    |
| chore    | Maintenance tasks                                 |
| style    | Formatting-only changes                           |
| revert   | Revert previous changes                           |

---

# Context Selection

Infer a meaningful context whenever possible.

Preferred:

```text
feat(auth): ...
fix(api): ...
refactor(storage): ...
build(terraform): ...
build(cloudformation): ...
build(docker): ...
ci(github-actions): ...
docs(readme): ...
docs(architecture): ...
```

Avoid:

```text
feat(core): ...
fix(misc): ...
chore(update): ...
```

unless no better context exists.

---

# Summary Requirements

The summary line must:

* Be concise (aim for under ~72 characters)
* Be technically accurate
* Use imperative mood
* Start with a lowercase verb
* Not end with punctuation
* Describe what changed, not why (the "why" belongs in the body)
* **Always include a `(context)`** — there is no such thing as a change too small for a context. A one-line style tweak still gets `style(app): ...` or `style(ui): ...`, never a bare `style: ...`.

---

# Git Invocation Requirements

A bare single `git commit -m "..."` is never sufficient — it can't hold the required bullet list. Every commit needs the summary plus bullets, produced one of two ways:

* Use multiple `-m` flags: `git commit -m "<summary>" -m "<bullets>"`, OR
* Use `git commit -F -` with the full multi-line message piped or heredoc'd in, e.g.:

```bash
git commit -F - <<'EOF'
feat(auth): add refresh token rotation

- Implement refresh token issuance flow with single-use enforcement
- Store token metadata securely
- Add token revocation support triggered on reuse detection
- Extend authentication tests to cover rotation and replay scenarios
EOF
```

Before running any `git commit`, check: a bare single `-m "..."` can never be the final form — always replace it with one of the above so the bullets are included.

Good:

```text
feat(auth): add refresh token rotation

- Implement refresh token issuance flow with single-use enforcement
- Store token metadata securely
- Add token revocation support triggered on reuse detection
```

Bad:

```text
Added refresh token rotation
Implemented cache fixes.
Various updates
fix(cache): prevent stale session lookups
```

---

# Bullet Point Rules

Bullets are mandatory on every commit, not optional. Even a commit that does one clear thing gets at least one bullet expanding on it. Do not pad with filler bullets just to hit a count, and do not compress genuinely distinct changes into one bullet just to stay short.

Bullets should:

* Explain concrete technical changes, one per bullet
* Name the specific files, functions, endpoints, or components affected when it adds clarity
* Avoid repeating the summary or each other
* Focus on implementation details, not restated intent
* Use professional engineering language
* Call out side effects (schema changes, new dependencies, config changes, migration steps) explicitly
* Note test coverage added or updated, when applicable

Example:

```text
feat(api): add user registration endpoint

- Implement registration service layer in services/user_registration.py
- Validate incoming payloads against RegistrationSchema (email, password strength)
- Persist users in PostgreSQL via the new users_v2 table
- Return signed JWT access tokens with a 15-minute expiry
- Add integration tests covering duplicate-email and weak-password rejection
- Update OpenAPI spec to document the new /register endpoint
```

---

# Infrastructure Rules

Use:

```text
build(cloudformation)
```

for CloudFormation changes.

Use:

```text
build(terraform)
```

for Terraform changes.

Use:

```text
build(docker)
```

for Dockerfile, Compose, ECR, image, and container-related changes.

Use:

```text
ci(github-actions)
```

for GitHub Actions workflows.

Use:

```text
ci(argocd)
```

for GitOps and ArgoCD changes.

---

# Breaking Changes

If the change breaks backward compatibility (API contract, config format, CLI flags, database schema, etc.), append a footer:

```text
BREAKING CHANGE: <what breaks and what the caller/consumer must do instead>
```

Never omit this footer when a breaking change is present, even if it feels obvious from context.

---

# Repository Preferences

* Prefer descriptive contexts.
* Favor readability six months later over brevity today.
* Favor refactor over chore when code structure changes.
* Favor build for infrastructure modifications.
* Favor ci for automation changes.
* Favor docs for architecture and design documentation.
* Never invent changes not present in the diff.
* Never misrepresent modifications.
* Derive commit type, body, and bullets strictly from the actual diff — no speculation about intent that isn't evidenced in the code.

---

# Output Requirements

Output only the final commit message.

Do not include:

* Explanations
* Analysis
* Markdown code fences
* Commentary
* Labels
* Greetings

The generated output must be directly usable as a git commit message.

---

# Validation Checklist

Before producing a commit message, verify:

* Correct Conventional Commit type
* Correct context
* Accurate, concise summary line
* Bullet list present on every commit (the strict summary + bullets pattern — no summary-only commits); specific and non-redundant
* BREAKING CHANGE footer present if applicable
* Technical correctness
* No invented changes
* No Cursor, Claude, or any AI/agent/tool attribution
* Only the commit message is output