145 lines
4.2 KiB
Markdown
145 lines
4.2 KiB
Markdown
---
|
|
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 <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
|
|
|
|
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)?"
|