Commit Zh
Explicitly invoke commit-zh to draft a Conventional Commits message with an English subject and Chinese body from staged diffs before you commit.
Overview
commit-zh is an agent skill most often used in Ship (also Build, Operate) that generates Conventional Commits messages with an English subject and Chinese body from staged changes when you invoke it explicitly.
Install
npx skills add https://github.com/blackhole1/bh-skills --skill commit-zhWhat is this skill?
- Conventional Commits with English subject line and 中文 body
- Manual invocation only: /commit-zh or $commit-zh (disable-model-invocation)
- Preloads git status, staged stat, recent log, and capped staged diff for context
- Hard rule: subject capped at 68 characters
- Staging and committing remain user decisions—agent must not commit without review
- Subject line maximum 68 characters
- Staged diff context capped at 500 lines in the skill template
Adoption & trust: 1 installs on skills.sh; 4 GitHub stars; trending (+100% hot-view momentum).
What problem does it solve?
You have staged changes but need a bilingual, convention-compliant commit message you can trust before running git commit yourself.
Who is it for?
Solo builders who commit in Chinese for teammates or changelog readers but want English subjects for tooling and Conventional Commits parsers.
Skip if: Workflows that require fully English messages, autonomous commits without human review, or repos where implicit agent invocation is required.
When should I use this skill?
You have staged changes and explicitly run /commit-zh or $commit-zh to produce an English-subject, Chinese-body Conventional Commits message.
What do I get? / Deliverables
You receive a review-ready Conventional Commits draft with English subject and Chinese body while you retain full control of staging and the actual commit.
- Conventional Commits message draft
- English subject ≤68 characters
- Chinese commit body
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Polished, reviewable commit messages are a Ship-phase hygiene step even though you run it throughout development. The skill supports pre-commit review and message quality—the same gate as code review—rather than IDE configuration or launch copy.
Where it fits
Draft a feat/fix subject and Chinese rationale before merging a hotfix branch.
Capture bilingual intent in commits while splitting a multi-day feature branch.
Document production tweak commits in Chinese for on-call readers while keeping English subjects for automation.
How it compares
Explicit bilingual commit generator with git read context—not a general PR description or squash-merge bot.
Common Questions / FAQ
Who is commit-zh for?
Developers using Claude Code or Codex who want English Conventional Commit subjects with Chinese bodies and who prefer to trigger the skill manually.
When should I use commit-zh?
After git add, during Ship or Build, invoke /commit-zh or $commit-zh whenever you are about to commit and want a Chinese body; skip if you already finalized the message.
Is commit-zh safe to install?
It limits tools to git read commands and user prompts; still review Prism Security Audits and never let any skill run git commit without your explicit approval.
SKILL.md
READMESKILL.md - Commit Zh
interface: display_name: "Commit ZH" short_description: "Conventional Commits message — English subject, Chinese body" default_prompt: "Use $commit-zh to write a commit message for the staged changes." policy: allow_implicit_invocation: false --- name: commit-zh description: Generate a Git commit message following Conventional Commits, with an English subject line and a Chinese (中文) body. Manual-invocation only — run it explicitly with /commit-zh (Claude Code) or $commit-zh (Codex). Use it for committing staged changes when you want a Chinese commit body. disable-model-invocation: true allowed-tools: Bash(git diff *), Bash(git log *), Bash(git status *), AskUserQuestion, request_user_input --- # Commit ZH Generate a [Conventional Commits](https://www.conventionalcommits.org/) message with an **English subject** and a **Chinese body**. ## Git Context **Repository:** !`git rev-parse --is-inside-work-tree 2>/dev/null || echo "NOT_A_GIT_REPO"` **Branch:** !`git branch --show-current 2>/dev/null` **Status:** !`git status --short 2>/dev/null` **Diff stat:** !`git diff --staged --stat 2>/dev/null` **Recent commits (style reference):** !`git log --oneline -5 2>/dev/null` **Staged diff:** !`git diff --staged 2>/dev/null | head -500` ## Critical Constraints Staging and committing are the user's decisions, and a commit that appears without review erodes their trust in the tool. Treat the rules below as non-negotiable for that reason: 1. **Subject ≤ 68 characters** — the `<type>(<scope>): <description>` line 2. **NEVER run `git add`** — only prompt the user to stage files manually 3. **NEVER auto-commit** — always wait for explicit user confirmation 4. **Always show the full commit message first** — render the complete text in a fenced code block before any confirmation prompt ## Execution Flow ### 0. Validate Environment - If `NOT_A_GIT_REPO` appears in Repository → tell the user "Not a git repository.", stop - If Status is empty → tell the user "No changes in the working tree or staging area.", stop - If Diff stat is empty (nothing staged) → tell the user "No staged changes. Run `git add` to stage files first.", stop ### 1. Analyze Changes Use the injected context above: - **Diff stat** → file-level overview; identify which modules/areas changed - **Staged diff** → understand the actual code changes, intent, and impact - **If the diff is exactly 500 lines, assume it may be truncated** → generate from available context and tell the user the diff was large ### 2. Determine Type | Type | When to use | |------|-------------| | `feat` | New functionality visible to users | | `fix` | Correcting incorrect behavior | | `docs` | Only comments/docs changed | | `style` | Whitespace/formatting only, no logic change | | `refactor` | Code restructure, no behavior change | | `perf` | Measurable performance improvement | | `test` | Adding or modifying tests | | `build` | Build config or dependencies | | `ci` | CI pipeline changes | | `chore` | Miscellaneous maintenance tasks | | `revert` | Reverting a previous commit (body must cite the reverted commit SHA or original subject) | ### 3. Infer Scope In priority order: 1. **Branch name pattern** — `feature/auth-login` → `auth` 2. **Single directory changed** — all files under `src/auth/` → `auth` 3. **Single module/component** — only `Button.tsx` changed → `button` 4. **Multiple related areas** — comma-separated: `auth,api` (non-standard extension; some CI tooling may reject it) 5. **Widespread changes** — omit the scope Match the scope naming style from the **Recent commits** section to stay consistent with the project. ### 4. Write the Subject (≤ 68 characters) - **The subject description is always English**, regardless of the language the user writes in - Use the imperative mood: "add", "fix", "refactor" — NOT "added", "fixes", "refactored" - Be specific: "add JWT token refresh endpoint", NOT "update auth" - No trailing period - `type(scope):` followed by the English d