name	commit
description	Stage and commit changes with pre-flight checks, doc updates, and roadmap tracking.
argument-hint	[description]
disable-model-invocation	false
allowed-tools	Bash(cargo ) Bash(git )

Commit the current changes. Additional context from the user: $ARGUMENTS

Follow these steps:

Pre-flight checks (skip if no .rs, Cargo.toml, or Cargo.lock files were changed): Run these in parallel:
- cargo fmt --all -- --check --files-with-diff
- cargo clippy --all-targets --all-features -- -D warnings
- cargo test --all-targets --all-features
- If a check fails, try to fix it automatically for simple cases (e.g. run cargo fmt for formatting failures). For complex failures, stop and report.
Verify test coverage (skip if no code changes):
- Check if the changes are covered by existing tests.
- If new functionality was added without tests, add them before proceeding.
Analyze changes:
- Run git status and git diff to understand staged and unstaged changes.
- If there are both staged and unstaged changes, ask the user whether to add the unstaged changes or commit only what's staged — unless all changes clearly belong to the same logical change, in which case stage everything.
- $ARGUMENTS may provide additional context to incorporate into the commit message. If no context is provided and the changes are non-trivial, ask the user before proceeding.
Update documentation:
- Verify doc comments are up to date with the code changes.
- If the changes affect module structure or public API, update the Architecture section in CLAUDE.md.
- Stage any doc changes alongside the code changes.
Update roadmap:
- If the changes implement a feature listed in ROADMAP.md, update the Version column to main.
- Stage ROADMAP.md alongside the other changes.
Generate commit message:
- Follow the 50/72 rule: subject line 50 characters or less, body wrapped at 72 characters.
- Include a brief body (1-3 sentences) summarizing changes when needed.
- Keep commits focused and atomic — one logical change per commit.
- Proofread for grammar, technical accuracy, and completeness.
- Show the commit message to the user and wait for confirmation before committing.
- Do NOT enumerate the staged files in the confirmation message — the user already knows which files are staged from git status. Only show the commit title and body.
Commit: Stage the relevant files, then create the commit.
- The commit runs through the Bash tool, which is POSIX bash and may differ from the contributor's interactive shell. Pass the message on stdin via a quoted heredoc so shell quoting cannot corrupt it:
```
git commit -F - <<'COMMIT_MSG'
<subject line>

<body wrapped at 72>
COMMIT_MSG
```
- Do NOT use git commit -m "…" for a multiline or special-character message, and do not reach for your interactive shell's own here-string or quoting idioms — they may not be valid bash and can inject stray characters into the message. The quoted delimiter ('COMMIT_MSG') keeps $, backticks, and ! literal; UTF-8 (em-dashes, etc.) passes through fine.

Strictly forbidden — these restrictions are non-negotiable:

Do NOT add "Generated with Claude Code" or any AI generation notices.
Do NOT add "Co-Authored-By: Claude" or any AI co-author attribution.
Do NOT include any reference to AI assistance, generation, or automation.
Do NOT list staged files (paths, renames, file counts) in the confirmation message or commit body — git status is the source of truth and re-listing them is noise.

commit

このリポジトリの他の Skills

このリポジトリの他の Skills