Add /commit skill for safe git commit workflow
This commit is contained in:
commit
085097d19f
|
|
@ -0,0 +1,144 @@
|
|||
---
|
||||
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)?"
|
||||
Loading…
Reference in New Issue