Commit En

interface:
  display_name: "Commit EN"
  short_description: "Conventional Commits message — English subject and body"
  default_prompt: "Use $commit-en to write a commit message for the staged changes."
policy:
  allow_implicit_invocation: false


---
name: commit-en
description: Generate a Git commit message following Conventional Commits, entirely in English (subject and body). Manual-invocation only — run it explicitly with /commit-en (Claude Code) or $commit-en (Codex). Use it for committing staged changes when you want an all-English commit message.
disable-model-invocation: true
allowed-tools: Bash(git diff *), Bash(git log *), Bash(git status *), AskUserQuestion, request_user_input
---

# Commit EN

Generate a [Conventional Commits](https://www.conventionalcommits.org/) message in **English**.

## Git Context

**Repository:** !`git rev-parse --is-inside-work-tree 2>/dev/null || echo "NOT_A_GIT_REPO"`
**Branch:** !`git branch --show-current 2>/dev/null`
**Status:**
!`git status --short 2>/dev/null`

**Diff stat:**
!`git diff --staged --stat 2>/dev/null`

**Recent commits (style reference):**
!`git log --oneline -5 2>/dev/null`

**Staged diff:**
!`git diff --staged 2>/dev/null | head -500`

## Critical Constraints

Staging and committing are the user's decisions, and a commit that appears
without review erodes their trust in the tool. Treat the rules below as
non-negotiable for that reason:

1. **Subject ≤ 68 characters** — the `<type>(<scope>): <description>` line
2. **NEVER run `git add`** — only prompt the user to stage files manually
3. **NEVER auto-commit** — always wait for explicit user confirmation
4. **Always show the full commit message first** — render the complete text in a fenced code block before any confirmation prompt

## Execution Flow

### 0. Validate Environment

- If `NOT_A_GIT_REPO` appears in Repository → tell the user "Not a git repository.", stop
- If Status is empty → tell the user "No changes in the working tree or staging area.", stop
- If Diff stat is empty (nothing staged) → tell the user "No staged changes. Run `git add` to stage files first.", stop

### 1. Analyze Changes

Use the injected context above:

- **Diff stat** → file-level overview; identify which modules/areas changed
- **Staged diff** → understand the actual code changes, intent, and impact
- **If the diff is exactly 500 lines, assume it may be truncated** → generate from available context and tell the user the diff was large

### 2. Determine Type

| Type | When to use |
|------|-------------|
| `feat` | New functionality visible to users |
| `fix` | Correcting incorrect behavior |
| `docs` | Only comments/docs changed |
| `style` | Whitespace/formatting only, no logic change |
| `refactor` | Code restructure, no behavior change |
| `perf` | Measurable performance improvement |
| `test` | Adding or modifying tests |
| `build` | Build config or dependencies |
| `ci` | CI pipeline changes |
| `chore` | Miscellaneous maintenance tasks |
| `revert` | Reverting a previous commit (body must cite the reverted commit SHA or original subject) |

### 3. Infer Scope

In priority order:

1. **Branch name pattern** — `feature/auth-login` → `auth`
2. **Single directory changed** — all files under `src/auth/` → `auth`
3. **Single module/component** — only `Button.tsx` changed → `button`
4. **Multiple related areas** — comma-separated: `auth,api` (non-standard extension; some CI tooling may reject it)
5. **Widespread changes** — omit the scope

Match the scope naming style from the **Recent commits** section to stay consistent with the project.

### 4. Write the Subject (≤ 68 characters)

- Use the imperative mood: "add", "fix", "update" — NOT "added", "fixes", "updated"
- Be specific: "add JWT refresh endpoint", NOT "update auth"
- No trailing period
- Lowercase the first letter after the colon

### 5. Write the Body

**Always include a body.** Write prose sentences explaining **why** the change was made:

- Separate it from the subject with