commit-message

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:

1. Analyze staged changes
2. Determine affected packages/scope
3. 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:

1. Type - What kind of change is this?
2. Scope - Which package(s) are affected?
3. Description - What does this change do?
4. 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

Derive scope from changed file paths:

• packages/<name>/** → use <name> as scope (e.g., core, postgres, sqlite)
• 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

1. Type: lowercase, from the table above
2. Scope: lowercase, optional, in parentheses
3. 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
4. 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:

• feat and fix changes 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)