Commit Message

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:

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

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)

Converted and distributed by TomeVault — claim your Tome and manage your conversions.