♻️ refactor(skills): standardize first-party skill contracts

upgrade commit-message, style-cleanup, and bulk-refactor-workflow
to use trigger-focused frontmatter and a shared contract structure.

add a first-party skill quality test gate and register it in tests
documentation.

skills/commit-message/SKILL.md

@@ -1,61 +1,98 @@
 ---
 name: commit-message
-description:
-  "基于 staged diff 生成符合 commit_message.md 的提交信息建议（:emoji:
-  type(scope): subject）。Triggers: commit message, 提交信息, 写提交说明,
-  生成提交信息, emoji commit, git commit."
+description: Use when the user asks for help writing a commit message, wants emoji/type(scope): subject formatting, or asks to review staged changes before committing.
 ---
 
 # Commit Message（提交信息建议器）
 
-目标：基于 `git diff --cached`（staged
-diff）生成 1–3 条提交信息建议：`:emoji: type(scope): subject`（可选 body/footer）。
+## Overview
 
-权威规范（单一真源）：
+Turn a staged diff into a commit recommendation that matches repository policy.
+Core principle: understand staged intent and commit boundaries before drafting the
+message.
+
+Authority source:
 
 - `docs/common/commit_message.md`
+- `docs/standards/playbook/docs/common/commit_message.md` (vendored playbook)
 
-## When to use
+## When to Use
 
-- 用户要“写提交信息 / 生成 commit message / 按规范写提交说明 / emoji commit”
-- 已经 `git add` 了一批改动，准备 `git commit`
+- The user asks to write or improve a commit message
+- The user wants emoji/type(scope): subject formatting
+- The user asks whether current staged changes should be split before commit
+- The user asks to review staged changes before running `git commit`
 
-## Procedure（default）
+## When Not to Use
 
-1. **收集 staged 概览（尽量小上下文）**
+- No staged changes exist and the user expects a final commit message based on the
+  actual staged diff
+- The task is writing a PR title, release note, or changelog instead of a git
+  commit message
+- The user already provided an exact commit message and only wants it executed
 
-   - `git diff --cached --name-status`
-   - `git diff --cached --stat`
-   - 必要时只看关键文件：`git diff --cached -- <path>`
+## Inputs
 
-2. **读取并遵循权威规范**
+- Current staging state (`git status --short`, `git diff --cached`)
+- Nearest applicable `commit_message.md`
+- Whether the user wants suggestions only or a command-ready final message
 
-   - 优先读取就近的
-     `commit_message.md`（见上方路径），以其中的 type/emoji/格式为准。
+## Procedure
 
-3. **生成 1 条主建议 + 2 条备选**
+1. **Baseline the repo state**
 
-   - 格式固定：`:emoji: type(scope): subject`（scope 可省略）。
-   - subject 用一句话描述“做了什么”，避免含糊词；尽量 ≤ 72 字符，不加句号。
+   - Inspect staged and unstaged state separately.
+   - If nothing is staged, stop. Explain that a staged-diff-based recommendation
+     is unavailable and ask whether files should be staged first.
+   - If only unstaged changes exist, stop before proposing a final message. Offer
+     a draft only if the user explicitly wants one.
 
-4. **判断是否建议拆分提交**
+2. **Load the authority spec**
 
-   - 当 staged 同时包含多个不相关模块/目的时：建议拆分，并给出拆分方式（按目录/功能点/风险）。
+   - Prefer the nearest `commit_message.md`.
+   - Reuse its type, emoji, scope, and body/footer conventions exactly.
 
-5. **可选：补充 body/footer（如需要）**
+3. **Summarize staged intent**
 
-   - body：说明 why/impact/verify（按规范建议换行）。
-   - footer：任务号或 `BREAKING CHANGE:`（若有）。
+   - Read the staged diff at the smallest useful granularity.
+   - Identify the main logical change, affected areas, and whether the staged set
+     mixes unrelated work.
+   - If staged changes combine unrelated goals, strongly recommend splitting the commit
+     before drafting a single message. In other words, strongly recommend splitting
+     the commit instead of hiding multiple intents behind one subject.
 
-6. **只给建议，不默认执行 `git commit`**
-   - 仅当用户明确要求时，才根据选定方案生成最终提交信息。
+4. **Draft message options**
 
-## Output contract（固定输出）
+   - Produce one recommended option and up to two alternatives.
+   - Keep the subject concrete, specific, and under the repo limit.
+   - Use body/footer only when they add real context such as motivation, impact,
+     verification, issue links, or breaking-change notes.
 
-- Detected: staged files summary（文件数 + 关键路径 + 是否可能需要拆分）
-- Proposed:
-  - Option A（recommended）：`:emoji: type(scope): subject`
-  - Option B：...
-  - Option C：...
-- Optional body/footer（如适用）
-- Notes：规范路径命中情况（哪个 `commit_message.md` 被使用）
+5. **Finalize safely**
+
+   - Make it explicit whether the output is a suggestion or a final chosen message.
+   - Do not run `git commit` unless the user explicitly asks for execution after
+     reviewing the recommendation.
+
+## Output Contract
+
+- `Detected:` staged files summary, dominant intent, and split/no-split judgment
+- `Spec:` which `commit_message.md` was used
+- `Proposed:` Option A (recommended), Option B, Option C
+- `Optional body/footer:` only when justified
+- `Notes:` risks, ambiguity, or split advice
+
+## Success Criteria
+
+- The recommendation matches the staged diff rather than guessed intent
+- The selected format complies with the nearest commit policy
+- Split advice appears when staged changes are logically mixed
+- No commit command is executed unless the user asked for it
+
+## Failure Handling
+
+- If no staged diff exists, stop and explain the limitation instead of inventing a
+  final message
+- If the staged set is too broad or ambiguous, recommend splitting and explain why
+- If no local policy file is found, state the fallback convention before drafting
+- If repo state changes during review, rerun the staged summary before finalizing