chore: update git-commit skill configuration

Add message validation step and clarify -m flag usage rules
for the git-commit skill.

Author: orrisroot

.agents/skills/git-commit/SKILL.md

@@ -4,7 +4,7 @@ metadata:
     github-path: skills/git-commit
     github-ref: refs/heads/main
     github-repo: https://github.com/orrisroot/agent-skills
-    github-tree-sha: e578a03c4a4295e65d0b0ef737d9ee979fbf08a0
+    github-tree-sha: 332b6fc533ae9085eafbba6827ff7798c85e4b38
 name: git-commit
 ---
 # Git Commit Operator
@@ -29,7 +29,22 @@ You must execute the following sequential workflow whenever a commit task is ini
 1. Construct the message draft strictly using the type classifications and syntax limits specified in `references/conventional_commits.md`.
 2. Present the drafted structure to the user for validation, highlighting the assigned commit type and scope.
 
-### Step 3: Terminal Command Delivery
-1. Upon user confirmation, output the explicit, single-line terminal command using multiple `-m` flags as specified in the formatting policy.
+### Step 3: Message Validation
+1. After drafting the message in Step 2, validate it against **every rule** listed in `references/conventional_commits.md` before proceeding. Check the following:
+   * **Type:** The commit type must be one of the allowed types (feat, fix, docs, style, refactor, perf, test, build, ci, chore, revert).
+   * **Language:** The entire message must be in English (unless the user explicitly requested another language).
+   * **Case & Punctuation:** The description must be lowercase and must NOT end with a period.
+   * **Imperative Mood:** The description must use imperative mood (e.g., "add", not "added" or "adds").
+   * **Line Length:** The subject line must not exceed 72 characters. **Every line in the body must also be wrapped at 72 characters or less.** If any line exceeds this limit, insert line breaks to fix it.
+   * **`-m` Flags:** The command must use at most three `-m` flags (one per structural part). Body lines must NOT be split across multiple `-m` flags.
+   * **Literal Newlines:** Multi-line body/footer content must use **literal newlines** inside double-quoted strings, NOT `\n` escape sequences (which shells commit as literal backslash-n).
+   * **Co-authored-by:** No `Co-authored-by:` trailers unless explicitly requested.
+2. If **any** rule is violated, fix the draft and re-validate from step 1. Repeat this loop until all checks pass. Only proceed to Step 4 once the message passes every validation check.
+
+### Step 4: Terminal Command Delivery
+1. Upon user confirmation, output the explicit, single-line terminal command using at most three `-m` flags as specified in the formatting policy.
+   * **CRITICAL:** Use at most one `-m` flag per structural part (Subject, Body, and Footer).
+   * **NEVER** use multiple `-m` flags for individual lines or bullet points within the body. Doing so causes Git to insert unwanted blank lines.
+   * **CRITICAL:** For multi-line body or footer content, you must use a single double-quoted string containing **literal newlines (actual line breaks)** within the command. Do NOT use escape sequences like `\n` (which shell command execution will commit literally) or additional `-m` flags.
 
 Process each step in order and complete the current step before moving to the next.

.agents/skills/git-commit/references/conventional_commits.md

@@ -35,15 +35,21 @@ When drafting, validating, or executing Git commits, you must strictly adhere to
    * The subject line (first line) must not exceed 72 characters, ideally 50 characters or less.
    * **Every single line within the commit message body must also be wrapped at 72 characters or less.** If an explanation runs longer, you must manually insert line breaks to keep each line under the 72-character threshold.
 
-3. **Part Separation via Multiple `-m` Flags**:
-   * Use one `-m` flag per structural part: the subject line, the body, and the footer. Use at most three `-m` flags in total.
-   * All body content — including bullet lists and multi-sentence explanations — must be placed in a single `-m` value. Do not split body content across multiple `-m` flags; doing so inserts unwanted blank lines between items.
+3. **Part Separation via Multiple `-m` Flags (At Most Three)**:
+   * Use at most one `-m` flag per structural part: the subject line, the body, and the footer. Use at most three `-m` flags in total.
+   * **NEVER split body lines or bullet lists across multiple `-m` flags.** Doing so inserts unwanted blank lines because Git automatically treats each `-m` flag as a separate paragraph.
+   * **DO NOT use escape sequences like `\n` in double quotes.** Shells like bash will treat `\n` as literal backslash-n characters and commit them as-is.
+   * **Use literal newlines (actual line breaks)** inside double quotes to write multi-line bodies or footers.
    * *Example:*
 
      ```bash
-     git commit -m "feat(auth): add jwt authentication" -m $'Validate tokens on every incoming request.\nSecure endpoints by rejecting expired credentials.\n- Added middleware for token validation\n- Removed legacy session handling' -m "BREAKING CHANGE: The old session-based cookie auth is deprecated."
+     git commit -m "feat(auth): add jwt authentication" -m "Validate tokens on every incoming request.
+     Secure endpoints by rejecting expired credentials.
+     - Added middleware for token validation
+     - Removed legacy session handling" -m "BREAKING CHANGE: The old session-based cookie auth is deprecated."
      ```
 
+
 4. **Co-authored-by Restriction**:
    * **Do not include any `Co-authored-by:` trailers** in the commit message or footer unless the user explicitly requests you to add credit for a co-author.
 
@@ -52,3 +58,20 @@ When drafting, validating, or executing Git commits, you must strictly adhere to
 
 6. **Imperative Mood**:
    * Always use the imperative mood in the description (e.g., use "add", "fix", "change" instead of "added", "fixes", "changed").
+
+## Validation Checklist
+
+When validating a draft commit message, check **every** item below. If any check fails, fix the issue and re-validate until all pass.
+
+| # | Check | Rule |
+|---|-------|------|
+| 1 | **Type valid** | The type must be one of: feat, fix, docs, style, refactor, perf, test, build, ci, chore, revert. |
+| 2 | **Language** | The message must be in English (unless the user explicitly requested another language). |
+| 3 | **Lowercase** | The description must be lowercase. |
+| 4 | **No period** | The description must NOT end with a period. |
+| 5 | **Imperative mood** | Use imperative mood (e.g., "add" not "added", "adds"). |
+| 6 | **Subject ≤ 72 chars** | The subject line must not exceed 72 characters. |
+| 7 | **Body lines ≤ 72 chars** | **Every line in the body must be wrapped at 72 characters or less.** |
+| 8 | **At most 3 `-m` flags** | Use at most one `-m` per structural part; do NOT split body lines across multiple `-m` flags. |
+| 9 | **Literal newlines** | Multi-line body/footer must use literal newlines inside double quotes, NOT `\n` escape sequences. |
+| 10 | **No Co-authored-by** | Do not include `Co-authored-by:` unless explicitly requested. |