commit

name	commit
description	Analyzes changed files and creates a git commit adhering to the Conventional Commits 1.0.0 specification. Use when asked to "commit these changes", "make a commit", "run git commit", or "save changes". Enforces branch checks, secret scanning, and mandatory Jira ticket references in the footer.

Commit Code Changes

Follow these instructions to create a commit based on the project's Conventional Commits conventions.

Step 1: Verify the Current Branch

Check the current git branch before committing:

git branch --show-current

If the current branch is main or master, stop and ask the user to create a new branch, or ask for explicit permission to commit to the main branch. Do not proceed with the commit on main or master without explicit user permission.

Step 2: Check Domain-Specific Prerequisites

Step 3: Analyze Changes

Review the staged and unstaged changes to understand what has been modified. Do this to structure your commit message accurately.

git status
git diff
git diff --staged

1. If there are unstaged changes that should be included, ask the user if you should stage them (git add <files>), unless they explicitly asked you to commit everything.
2. Verify that no secrets, tokens, or credentials are included in the changes.
3. Verify that no unwanted files or artifacts are being committed (check .gitignore).

Step 3: Formulate the Commit Message

Construct a commit message strictly following the Conventional Commits 1.0.0 specification.

Message Format:

<type>(scope): <description>

[optional body]

[optional footer(s)]
Refs: <Ticket-ID>

Types:

Type	Purpose
feat	New feature
fix	Bug fix
ref	Refactoring (no behavior change)
perf	Performance improvement
docs	Documentation only
test	Test additions or corrections
build	Build system or dependencies
ci	CI configuration
chore	Maintenance tasks
style	Code formatting (no logic change)

Subject Line Rules:

• Keep it concise.
• Use the imperative, present tense: "add feature" not "added feature".
• Do not capitalize the first letter.
• Do not end with a period.

Body Guidelines:

• The body MUST begin one blank line after the description.
• Explain what and why, contrast with previous behavior if necessary.

Footer Rules:

• The footer MUST begin one blank line after the body (if body exists) or description.
• Every commit must include a Jira reference in the footer formatted exactly as: Refs: <Ticket-ID> (e.g., Refs: JI-1234), unless explicitly instructed otherwise by the user. If the user hasn't provided a ticket ID, ask for it before proceeding.
• If there is a breaking change, either add BREAKING CHANGE: <description> to the footer or include a ! immediately before the colon in the prefix (e.g., feat(api)!: <description>).

Step 4: Review and Prepare the Commit

Once the commit message is fully formulated and all checks pass, stop and present the final commit command to the user for review. Do not execute the commit automatically.

Provide the command in a format the user can easily copy or approve:

git commit -m "type(scope): description" -m "body text here" -m "Refs: JI-1234" -m "Co-Authored-By: <Agent Name> <Agent Email>"

Ask the user: "Does this commit message and command look correct?" Wait for their approval before proceeding to execute it upon their request.

Report back to the user that the commit has been successfully created.