# Create Commit > Stage files, generate a commit message in this repo's Conventional Commits style, and commit after user approval. - Skill: `digital-go-jp/create-commit` (Agent Skill) - Install (CLI): `npx skillmds@latest add digital-go-jp/create-commit` - Raw SKILL.md: https://api.skillmd.com/api/skills/digital-go-jp/create-commit/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: digital-go-jp (https://skillmd.com/u/digital-go-jp) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/digital-go-jp/create-commit --- ## Context - Current git status: !`git status` - Current git diff (staged and unstaged changes): !`git diff HEAD` - Current branch: !`git branch --show-current` - Recent commits: !`git log --oneline -10` ## General rules - Commit messages follow [Conventional Commits](https://www.conventionalcommits.org/), and the conventions in `AGENTS.md` § _Commit messages_. - Description: English, imperative mood (e.g. "add", not "added" / "adds"), no leading capital, no trailing period, ≤ 72 characters. - Body (when included): English, wrap at ~72 characters, blank line after the description, explain **what / why** (not how). - For breaking changes, add `!` after the type or type+scope (e.g. `feat!:`, `feat(Button)!:`). ## Workflow ### 1. Check changes and stage files ```bash git status --short ``` If there are no changes at all, stop and tell the user there is nothing to commit. If there are unstaged changes, use `AskUserQuestion` (`multiSelect: true`) to ask which files to stage: - First option: **"Stage all"** — stages every unstaged/untracked file. - Then list each individual unstaged/untracked file. If files are already staged, mention them in the question text so the user knows what is already in the index. If everything is already staged, skip to step 2. After the selection, stage with `git add` (specific files; avoid `git add -A` / `git add .` so we don't accidentally pick up secrets or large binaries): ```bash git add ... ``` ### 2. Verify staged changes ```bash git diff --cached --stat ``` If empty, stop and tell the user there is nothing to commit. ### 3. Analyze the diff and draft a commit message ```bash git diff --cached ``` For large diffs (>500 lines), start with `--stat` and read key files selectively. If needed for context: - Read the full file for new files. - Check `git log --oneline -5` to follow recent style. Draft a Conventional Commits message in this repo's style — see _Commit message format_ below — and **present it to the user via `AskUserQuestion` for approval**: - Option 1: Approve. - Option 2: Request changes (user provides feedback via "Other"). If the user requests changes, revise and ask again. **Do not run `git commit` until the user approves.** ### 4. Execute the commit Once approved: ```bash git commit -m "" ``` For multi-line messages (body / footer), use a HEREDOC: ```bash git commit -m "$(cat <<'EOF' ():