commit-message
Generate a conventional commit message from staged changes. Analyzes changes to determine affected packages and appropriate commit type, then outputs a properly formatted commit message.
安装与使用
请根据来源仓库和你的 AI 工具说明安装此技能。先阅读技能文件和依赖要求,再添加到工作流。
查看来源 ↗使用指南技能说明
Commit Message Generator
Generate a conventional commit message suitable for use with the changesets library. This skill analyzes your staged changes and creates a properly formatted commit message.
Instructions
When this skill is invoked:
- Analyze staged changes
- Determine affected packages/scope
- Generate a conventional commit message
Usage
/commit-message # Generate commit message from staged changes
Process
Step 1: Gather Changes
Run these commands to understand the changes:
git diff --staged --name-only
git diff --staged
If nothing is staged, inform the user they need to stage changes first.
Step 2: Analyze Changes
Determine:
- Type - What kind of change is this?
- Scope - Which package(s) are affected?
- Description - What does this change do?
- Breaking - Is this a breaking change?
Step 3: Map to Conventional Commit Types
| Type | When to Use | Semver Impact |
|---|---|---|
feat |
New feature or capability | minor |
fix |
Bug fix | patch |
refactor |
Code change that doesn't fix a bug or add a feature | patch |
perf |
Performance improvement | patch |
docs |
Documentation only | none |
chore |
Maintenance, dependencies, configs | none |
test |
Adding or fixing tests | none |
build |
Build system or external dependencies | none |
ci |
CI configuration | none |
Step 4: Determine Scope
Map changed files to package scopes:
| Path Pattern | Scope |
|---|---|
packages/core/** |
core |
packages/postgres/** |
postgres |
packages/sqlite/** |
sqlite |
packages/mongodb/** |
mongodb |
packages/redis/** |
redis |
packages/nats/** |
nats |
packages/otel/** |
otel or observability |
examples/** |
examples |
docs/** |
docs |
If multiple packages are affected equally, omit the scope or use the primary one.
Step 5: Generate Commit Message
Format: type(scope): description
For breaking changes: type(scope)!: description
Rules
- Type: lowercase, from the table above
- Scope: lowercase, optional, in parentheses
-
Description:
- Start with lowercase verb (add, fix, update, remove, change)
- Use imperative mood ("add feature" not "added feature")
- No period at the end
- Max ~50 characters for the first line
-
Breaking changes: Add an exclamation mark before the colon (e.g.,
feat!:)
Examples from this project
feat(core): add JobTypeRegistry with compile-time and runtime validation
fix(core): prevent context leakage to independent chains during job processing
refactor: rename JobSequence to JobChain across entire codebase
refactor(core): simplify index.ts exports, move in-process adapters to internal
chore(examples): enable isolatedModules in all tsconfig files
docs: address publish readiness issues
feat(observability): add gauge metrics for worker idle/processing state
refactor!: change Log API from tuple args to named data/error properties
Step 6: Output
Provide the commit message in a code block that can be easily copied:
feat(core): add new feature description
If the change is significant, also suggest whether a changeset file is needed:
-
featandfixchanges to packages → changeset recommended -
docs,chore,test→ usually no changeset needed
Multi-line Commit Messages
For complex changes, provide an extended format:
type(scope): short description
Longer explanation of the change if needed.
Explain the motivation and contrast with previous behavior.
BREAKING CHANGE: description of what breaks (if applicable)
使用示例
查看来源仓库中的使用示例与配置说明。
查看来源 ↗来源历史
- 收录时间
- 2026-01-20
- 索引更新时间
- 2026-01-26
- Branch
- main
收录与同步日期属于本站记录。源码修改历史请查看来源仓库。
GitHub ↗chat Comments (0)
Sign in to join the discussion and leave a comment.
No comments yet. Be the first to share your thoughts!