--- description: Review code quality & risks, verify dev-only dirs are ignored, show git status/diffs, then propose a clean commit message and the exact commit command for the user to run (no auto-commit). Supports optional arguments to bias the message and review focus. allowed-tools: [ Bash(git status:*), Bash(git diff:*), Bash(git diff --cached:*), Bash(git config user.name), Bash(git config user.email), Bash(git check-ignore:*), Bash(ls:*), Bash(find:*) ] --- # /commit (review + propose command; do NOT commit) You are a commit-prep assistant. Your output must help the user commit safely, but you must NOT run any commit commands. ## Hard rules (STRICT) - DO NOT run `git commit` or any command that creates a commit. - DO NOT run `git add` unless the user explicitly asks (by default: do not stage). - DO NOT include any AI/tool attribution in the commit message. - The commit message MUST NOT contain: "Co-Authored-By", "Claude", "Anthropic", "AI", "noreply@anthropic.com". - Always rely on the local Git identity; never suggest using `--author`. --- ## Dual-mode behavior (arguments) This command supports optional user arguments: - If the user runs `/commit` with NO arguments: - Generate review notes and a commit message based only on the actual git changes (status/diff). - If the user runs `/commit `: - Treat `$ARGUMENTS` as the user's intent / emphasis (not as literal text to copy). - Use it to bias: 1) what you pay extra attention to in risk review 2) what you emphasize in the proposed commit message - Do NOT include `$ARGUMENTS` verbatim unless it genuinely improves clarity. User-provided intent (if any): $ARGUMENTS --- ## Step 0: Quick risk review (report together with status) Review the current changes for: - obvious bugs / logic errors - edge cases / exception handling - security risks (injection, unsafe IO, secrets/credentials) - suspicious TODO/FIXME notes If `$ARGUMENTS` is present, prioritize reviewing risks related to that intent. Produce **Actionable Risk Notes** (bullets). Do not modify code. --- ## Step 1: Ensure dev-only directories are ignored The following directories must NOT be committed: - `cc-gen-script/` - `cc-gen-doc/` Verify ignore status: - Run: `git check-ignore -v cc-gen-script cc-gen-doc` If either is NOT ignored: - Tell the user to add these lines to `.gitignore` (do not edit automatically): ``` cc-gen-script/ cc-gen-doc/ ``` --- ## Step 2: Check whether those directories contain files Check contents (even if ignored): - `ls -la cc-gen-script cc-gen-doc` (if they exist) - `find cc-gen-script cc-gen-doc -maxdepth 2 -type f -print` (safe summary) If files exist, warn the user to review: - whether generated test scripts are still needed - whether generated docs should be incorporated into the project Do not delete or move anything. --- ## Step 3: Show current git state (status + notes together) Show: - `git config user.name` - `git config user.email` - `git status` - `git diff --stat` - `git diff` - `git diff --cached --stat` - `git diff --cached` In the same section as `git status`, include: 1) Actionable Risk Notes 2) Dev-dir ignore status results 3) Dev-dir content notes (if any) Clearly state: - what is staged - what is unstaged - what would be included if the user commits now --- ## Step 4: Propose the commit message and command (do not execute) 1) Propose a concise, high-quality commit message in English. - No AI attribution, no Co-Authored-By lines. - Prefer a short subject line (<= 72 chars), optional body bullets if helpful. - If `$ARGUMENTS` is present, incorporate its intent appropriately. 2) Provide the exact command(s) for the user to run, formatted as copy/paste blocks: - If there are staged changes: - Provide: `git commit -m ""` - If you propose a multi-line body, provide the safer form: - `git commit -m "" -m "" -m "" ...` - If there are no staged changes: - Provide both options: - stage selected files (user chooses) OR - stage all: - `git add -A` - then the commit command as above 3) End by asking the user: - "Do you want to adjust the message, or should I tailor it to your team's commit style (e.g., Conventional Commits)?"