Type	Description
`feat`	New feature
`fix`	Bug fix
`docs`	Documentation only
`style`	Code style (formatting, semicolons, etc.)
`refactor`	Code change that neither fixes nor adds
`test`	Adding or updating tests
`chore`	Build, tooling, dependencies
`perf`	Performance improvement
`ci`	CI configuration changes
`build`	Build system or dependencies
`revert`	Reverting a previous commit

Rules

Subject: Short description, imperative mood, lowercase, no period at end
Scope: Optional, lowercase, describes what was changed (e.g., auth, api, ui)
Breaking changes: Add ! after type/scope: feat(auth)!: change API
Footer: For breaking changes (BREAKING CHANGE:) or issue references (Closes #123)

Operations

1. Generate Commit from Diff

When user wants to commit changes:

Run git status to see changed files
Run git diff --staged for staged changes
Analyze what changed to determine:
- Type: Which type best describes the changes?
- Scope: What area was affected? (optional)
- Subject: What was done? (imperative: "add" not "added")
Create a conventional commit message
Run git commit -m "<message>"

Example:

feat(auth): add JWT token refresh

Implements token refresh endpoint to extend sessions
without requiring re-authentication.

Closes #142

2. Validate Commit Message

When user asks to validate or check a commit message:

Parse the commit message
Check format: <type>(<scope>): <subject>
Validate type is from the allowed list
Check subject follows rules (lowercase, imperative, no period)
Flag any issues found

3. Create Pull Request

When user wants to open a PR or after finishing commits on a feature branch:

Verify on a feature branch (not main): git branch --show-current
Check for project PR template: ls .github/PULL_REQUEST_TEMPLATE.md
Push branch if needed: git push -u origin <branch>
Create PR via gh pr create:
- Use --fill if commits are clean (auto-populates title/body)
- Use --draft for work-in-progress
- Use interactive mode if body needs custom content
Show the PR URL to the user

See references/pr-workflow.md for full workflow details.

Input Methods

Input	Action
User says "commit" or "git commit"	Generate from git diff, then commit
User says "validate commit"	Check the commit message format
User pastes commit message	Validate the provided message

Auto-Commit Workflow

When generating a commit:

Show the user the commit message first
Ask for confirmation before committing (unless user explicitly says "just do it")
Execute git commit -m "<message>" after confirmation
Show the result of the commit

Error Handling

If no staged changes: git status shows nothing → warn user nothing to commit
If git not initialized: Initialize repo or warn user
If commit fails: Show error and offer to retry

Examples

Input: "I fixed the login bug" Output:

fix(auth): resolve login timeout issue

Users were logged out after 5 minutes due to
incorrect token expiry calculation.

Input: "I added a new API endpoint for users" Output:

feat(api): add user profile endpoint

GET /users/:id returns user profile data including
name, email, and avatar URL.

Closes #89

Input: "I changed the auth API, this breaks old clients" Output:

feat(auth)!: change token validation endpoint

The /auth/verify endpoint now requires Bearer token
instead of query parameter.

BREAKING CHANGE: Clients must update to send
Authorization header with Bearer token.

code-commit

Conventional Commit Skill

Conventional Commit Format

Types