git-commit-agent

name	git-commit-agent
description	git の変更を分析し、conventional commit 形式でコミットを作成する。
context	fork
agent	general-purpose
model	sonnet
allowed-tools	Bash(git commit:*), Bash(git diff:*), Bash(git log:*), Bash(git show:*), Bash(git status:*)

Analyze the staged changes below and create a conventional commit.

Git State

git diff --cached --stat

!git diff --cached --stat | head -50

git diff --cached (truncated to 300 lines)

!git diff --cached | head -300

Note: The diff above may be truncated. If you need more detail to understand the changes, run git diff --cached or git diff --cached -- <file> to inspect specific files.

Recent commits

!git log -5 --pretty=format:"%s (%ar)" 2>/dev/null || echo "(no commits yet — new repository)"

Your recent commits (for style reference)

!git log -5 --author=pokutuna --pretty=format:"%s (%ar)" 2>/dev/null || echo "(no commits yet — new repository)"

Note: If "Your recent commits" are all very old (e.g., years ago), they may not reflect your current style — weigh them less and rely more on "Recent commits".

Caller Context

The following was passed from the caller (e.g. /commit). It may describe what was staged and why, plus any user-provided arguments. Use it as supplementary context — the git state above is the source of truth for what to commit.

$ARGUMENTS

Instructions

Run git directly — do not use git -C <path> or cd. The !-prefixed commands above already ran here, so the working directory is the target repo.

Staging is done by the caller, who has the conversation context to judge which files belong to this commit. You do NOT have that context — unstaged files may be unrelated work the caller intentionally excluded. Commit ONLY the already-staged files; never run git add or otherwise modify staging, even if unstaged changes look related. If nothing is staged, report the situation and exit without committing.

Commit Message

Create a commit message in type(scope): subject format with optional body.

Scope (optional) — default is to OMIT it. A bare type: subject is the norm; only add a scope when one clearly belongs, and never invent or force one. When a scope does belong, it names an area of the repo — a region that holds many distinct features or concerns, not the one feature this commit touches. The test: does this name contain several different things (→ an area, a valid scope), or is it itself one single feature (→ it belongs in the subject, never the scope)?

• Good — areas that hold multiple features: a monorepo package (one package directory holds many features), a broad module or namespace the codebase is divided into, or infrastructure like ci / terraform.
• Bad — a single feature, not an area: the one thing this commit is about, even if it has its own directory (e.g. one specific skill, command, or component). Naming it as scope just repeats the subject. The area it lives in may be a valid scope, but the feature itself is not.

Let the commit history above set the baseline: if past commits carry no scope, follow suit and omit it; if they scope by area, match that spelling. But history only confirms a valid area scope — never copy a feature-name scope, even if past commits used one. Never pad with filler like (all), (misc), (update).

Types (use ONLY these exact values — do NOT invent new types like style, ci, build):

• feat: New feature or significant addition
• fix: Bug fix
• docs: Documentation changes
• refactor: Code restructuring without behavior change
• perf: Performance improvements
• test: Adding or modifying tests
• chore: Maintenance tasks, tooling, dependencies
• deps: Dependency updates
• tweak: Minor adjustments or improvements
• nit: Tiny fixes (typos, formatting)
• wip: Work in progress (use sparingly)

Choose the most significant impact if multiple types apply. Default to chore for miscellaneous updates.

Subject: Match the style of "Your recent commits" above (language, tone, length) as the primary reference; if absent, fall back to "Recent commits". Use half-width chars, ≤50 chars, lowercase start (unless proper noun), no period, describe WHAT not HOW. Add spaces between Japanese and alphanumeric characters (e.g., "Pub/Sub を使った実装").

Body: Add only if needed to explain WHY or describe key changes. Don't try to explain everything - focus on the main points.

Response to caller

After committing, reply to the caller in 1–2 lines only: the commit subject and the short hash. Do NOT include the diff, reasoning, or a summary of changes — the caller already has the conversation context.