Commit

Commit staged git changes with a clear, conventional commit message. The key principle: respect what the user has staged. If they haven't staged anything, let them know — don't silently stage files on their behalf, because that can lead to accidentally committing sensitive files, unfinished work, or large binaries.

Steps

Follow these steps in order.

Step 1: Check for staged changes

Run these commands in parallel to understand the current repo state:

• git diff --cached — shows what's staged and ready to commit

• git diff --cached --stat — a quick summary of staged files

• git status — shows the full picture (staged, unstaged, untracked). Do NOT use the -uall flag.

• git log --oneline -5 — recent commits, so you can match the project's commit message style

Step 2: Handle the "nothing staged" case

If git diff --cached is empty (nothing staged), inform the user clearly:

No changes are currently staged for commit.

Then show them what's available — unstaged modifications and untracked files from git status . Ask if they'd like you to stage specific files. List the files so they can pick.

Do not proceed to Step 3 until the user has explicitly told you what to stage, or confirmed they want to stage everything. If they ask you to stage files, run git add for only the files they specified, then continue.

If the user decides not to stage anything, skip directly to Step 5 (Log work in Jira).

Step 3: Draft the commit message

Analyze the staged diff and write a commit message following these conventions:

• Use conventional commit format: type(scope): description

• Types: feat , fix , refactor , docs , test , chore , style , perf , ci , build

• Scope is optional — use it when the change is clearly scoped to a module or area

• Keep the first line under 72 characters

• If the change is non-trivial, add a blank line followed by a brief body explaining the "why"

• Match the style of recent commits from git log when possible

• End with: Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Use a heredoc to pass the message so formatting is preserved:

git commit -m "$(cat <<'EOF' type(scope): description

Optional body explaining why.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> EOF )"

Step 4: Verify the commit

Run git status after the commit to confirm it succeeded.

If the commit fails due to a pre-commit hook, investigate the failure, fix the issue, re-stage the fixes, and create a new commit (never amend unless the user asks).

Show the user the commit hash and a brief summary of what was committed.

Step 5: Log work in Jira

Always invoke the sdapp-jira-log skill at the end of this workflow — whether or not a commit was made. This covers cases where the user committed successfully, had nothing to commit, or chose not to stage anything. The user expects to log time regardless of whether code was committed, because they may have spent hours reviewing, researching, or doing other work.

Do not ask for confirmation — just proceed directly:

Skill(skill: "sdapp-jira-log")

Important guardrails

• Never run git add . or git add -A without the user's explicit request — these can accidentally include .env files, credentials, or large binaries

• Never amend a previous commit unless the user specifically asks for it

• Never skip hooks (--no-verify ) or bypass signing unless explicitly asked

• Never force push

• If there are files that look sensitive (.env , credentials.* , *.pem , *.key ), warn the user before staging them even if they asked to stage everything