lsamc
/
cc-cmd
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
cc-cmd/commit.md

4.2 KiB
Raw Blame History

description allowed-tools
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.
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 <ADDITIONAL_MSG>:

    • 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 "<subject>"
    • If you propose a multi-line body, provide the safer form:
      • git commit -m "<subject>" -m "<body line 1>" -m "<body line 2>" ...

  • 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
  1. 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)?"