conventional-commit-review

原文涵盖的主题

• Conventional Commit Review
• When to Activate
• Core Concepts
• Workflow
• Code Examples
• Anti-Patterns
• Best Practices
• Related Skills

Turns a staged diff into a commit message that follows the Conventional Commits format (type(scope): subject) and matches the repository's actual history norms instead of a generic template. The user is about to run git commit and wants help with the message. The user asks "write a commit message for this", "is this commit message okay?", or "fix my commit message". A PR description needs a commit-style summary line. Any workflow step that produces a commit as part of a larger task (a refactor, a bugfix, a release) should route the final message through this skill rather than inventing a format ad hoc. Type first. Common subject prefixes are feat, fix, docs, style, refactor, perf, test, build, ci, or chore, optionally followed by a parenthesized scope: feat(auth): add refresh-token rotation. Use an established repository-specific prefix when its history requires one. Match the repo's own norm, don't assume one. Before writing the message, check the last 20-30 subject lines with git log --no-merges --format=%s -30 and measure: Do they use conventional prefixes at all, or a different convention? What's the typical subject length? (Many repos cluster around 50 characters; some, like t

这里只展示节选，请以完整原文和当前要求为准。