菜单
Write git commit messages that follow Conventional Commits. Keep them lean: the subject line states the intent in one line; add a body only when the diff can't speak for itself. Use when creating git commits, writing commit messages, splitting a working tree into commits, or when the user mentions "写 commit", "commit message", "提交信息", "提交规范".
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
Draft or rewrite GitHub Pull Request titles and descriptions — bug fixes, security fixes, features, refactors, dependency upgrades, rollbacks, plus release review notes and reviewer-facing change summaries. Use when the user mentions "写 PR", "PR 描述", "PR body", "review notes".
Write or rewrite a project README that converts a 10-second visitor into a user. Use when the user asks to write/rewrite/improve a README, mentions "写 README", "README 写作", "项目说明", or wants a README generated from existing code or notes. Front-loads identity → value → minimum-runnable example; cuts marketing fluff, premature API dumps, and decorative TOCs.
Use this skill when setting up, validating, or debugging npm package release pipelines for pnpm workspace monorepos, especially with GitHub Actions, npm Trusted Publisher, provenance, scoped public packages, pack/publish tarball flows, and CI failures around workspace dependencies, Vue/TypeScript monorepo wiring, or npm release metadata.
| name | commit-writing |
| description | Write git commit messages that follow Conventional Commits. Keep them lean: the subject line states the intent in one line; add a body only when the diff can't speak for itself. Use when creating git commits, writing commit messages, splitting a working tree into commits, or when the user mentions "写 commit", "commit message", "提交信息", "提交规范". |
Write the intent the diff cannot show; never restate the diff. The readers are people tracing "why was this line changed" through git log / git blame, and tooling that derives changelogs and semver bumps from the type.
Follow Conventional Commits; types, !, and BREAKING CHANGE work as the spec says and are not repeated here. Conventions beyond the spec:
add, not added), lowercase, no trailing period, ≤ 70 chars including type / scopegit log --onelinefixed bug / update auth / WIP / restating the diff / emoji / adjectives ("major improvement") / tooling metadata ("AI-assisted")fix(auth): race condition in token refresh under concurrent login, refactor(db): extract connection pool from request middlewareMost commits need no body. Add one only when the diff can't show it (blank line after the subject, wrap at 72 chars):
Refs: #123, Fixes: SEC-431) and hard numbers (reduces p95 from 800ms to 120ms)A body longer than the diff means it is restating code — cut everything the diff proves by itself.
Each commit is a unit that can be reviewed and reverted independently:
git add -p (git reset HEAD~ first if already mixed)