Conventional Commit from Staged Changes

When to Use

Apply this skill when the user asks to create a commit, write a commit message, or commit staged changes, especially when they mention conventional commits or a ticket number in the branch.

Workflow

0. Multi-root workspace: which project?

The user often has multiple projects in a single VS Code/Cursor workspace (e.g. a .code-workspace with several folders). Each folder is usually its own git repo.

• Do not run any commands to detect which project has staged changes.

• If it's unclear which project to generate the commit for, ask the user at the start (before running any git commands). Use the AskQuestion tool when available, with the workspace folder names as options; otherwise ask in chat (e.g. "Which project should I use for this commit?" and list the folder names).

• Only after the project is known, run git commands from that project's root (e.g. cd path/to/project && git ... or use the working_directory / cwd for that path).

1. Get branch name and staged changes

git branch --show-current git diff --staged --stat git diff --staged

Run these from the chosen project root. Use the output to infer scope and ticket. If no changes are staged, tell the user to stage first (git add ).

2. Extract ticket from branch name

Branch names often look like: PROJ-194-ui-mismatch-in-email-management , feature/JIRA-123-add-login , fix/ABC-456 .

• Match the first segment that looks like PREFIX-NUMBER (e.g. PROJ-194 , JIRA-123 ). Common patterns: uppercase letters + hyphen + digits.

• Use that as the scope in parentheses: (PROJ-194) , (JIRA-123) .

• If no ticket pattern is found, omit the scope or use a short scope from the change (e.g. module or area).

3. Choose conventional type

From the staged diff, pick one:

Type Use when

feat

New feature or user-facing capability

fix

Bug fix

chore

Build, tooling, deps, config, no app logic

docs

Documentation only

style

Formatting, whitespace, no logic change

refactor

Code change that is not a fix or feature

test

Adding or updating tests

perf

Performance improvement

Default to feat for new behavior, fix for defect fixes, chore for everything else when unclear.

4. Write the subject line

• Format: type(scope): imperative subject

• Scope = ticket ID from branch (e.g. PROJ-194 ).

• Subject: lowercase, imperative ("add" not "added"), no period at end, ~50 characters or less.

• Example: feat(PROJ-194): fix email management UI mismatch

5. Write the body (optional)

• Add a body if the change needs explanation (what changed and why).

• Put each item on its own line (no bullets); use newlines inside the body string.

• Wrap long lines at ~72 characters.

6. Output the git command (do not run it)

Output a copy-pastable git commit command for the user to run—do not execute git commit unless the user explicitly asks you to run it (e.g. "run it", "execute it", "commit for me"). Otherwise, only show the command so the user can review and run it themselves.

Use one -m for the subject; if there is a body, add a second -m with the body. Use real newlines inside the body string so each item is on a separate line. In a multi-root workspace, prefix with cd <project-path> && so the command runs in the chosen project, or tell the user to run it from that folder.

• Subject only: git commit -m "type(scope): subject"

• Subject + body (multiple items on separate lines): use one -m with newlines inside the quoted string.

Examples

Example 1

• Branch: PROJ-194-ui-mismatch-in-email-management

• Staged: Changes in email management modals and notification CC list UI.

git commit -m "feat(PROJ-194): align email management UI with design" -m "Update notification CC modals and list section to match specs Fix avatar and remitter sections styling"

Example 2

• Branch: fix/PROJ-200-login-timeout

• Staged: Increase auth timeout and retry logic.

git commit -m "fix(PROJ-200): increase login timeout and add retry" -m "Prevent session expiry during slow networks by extending timeout and retrying once on failure."

Example 3

• Branch: chore-deps

• No ticket in branch; staged: package.json and lockfile.

git commit -m "chore(deps): bump axios to 1.6.0"

Checklist

• If multi-root and project unclear, ask user which project at the start (do not run commands to detect)

• Read branch name and staged diff from the chosen project

• Ticket/scope from branch (or omit if none)

• Type chosen from content (feat/fix/chore/etc.)

• Subject: type(scope): imperative , < ~50 chars

• Body only if needed; one item per line; wrap at 72 chars

• Output a copy-pastable git commit command (not just the message); do not run git commit unless the user explicitly asks to run it