From 085097d19f095d1e5715bbb60d23ac375cd1ea5e Mon Sep 17 00:00:00 2001
From: lsamc <2322176165@qq.com>
Date: Thu, 22 Jan 2026 20:29:04 +0800
Subject: [PATCH] Add /commit skill for safe git commit workflow

---
 commit.md | 144 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 144 insertions(+)
 create mode 100644 commit.md

diff --git a/commit.md b/commit.md
new file mode 100644
index 0000000..6fcb8bb
--- /dev/null
+++ b/commit.md
@@ -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)?"