Commit

Announce: "I'm using the commit skill to create a structured git commit."

Step 1: Gather Context

Run in parallel:

•git status (never use -uall)
•git diff --staged
•git diff (unstaged changes)
•git log --oneline -5 (recent commit style reference)
•git branch --show-current (check branch name for ticket IDs like JIRA-1234)

If no staged and no unstaged changes: inform the user there is nothing to commit and stop.

Automatic exclusions: When staging files, always exclude:

•.plans/ directory and *.plan.md files (working documents for /do and /execplan)

If there are unstaged changes but nothing staged:

code

AskUserQuestion(
  header: "Stage files",
  question: "No files are staged. What would you like to commit?",
  options: [
    "All changes" -- Stage all modified and untracked files,
    "Let me choose" -- Show file list for selective staging
  ]
)

•"All changes": run git add -A, then unstage excluded files: git reset HEAD -- '.plans/' '*.plan.md' 2>/dev/null || true
•"Let me choose": list the changed files (excluding .plans/ and *.plan.md) and let the user specify which to stage

If there are already staged changes: proceed with those (do not touch unstaged files).

Step 2: Analyze Changes

Read the staged diff (git diff --staged) to understand what changed.

Determine:

•Title: a concise one-line summary of the changes. Use $ARGUMENTS as the title if provided. Otherwise, derive one from the diff.
•Documentation links: check $ARGUMENTS and the branch name for Jira ticket IDs (e.g., JIRA-1234, XX-123). Check for any RFC or doc URLs mentioned in $ARGUMENTS.
•Motivation: the "why" behind the changes — only if it is not obvious from the title alone.
•Summary: a bullet-point description of what changed and how — only if the changes need explanation beyond the title.

Step 3: Build Commit Message

Construct the commit message using this template. Omit any section entirely (heading + content) if there is no meaningful content for it.

code

<title line>

## 📎 Documentation

- [RFC]({URL})
- [JIRA]({URL})

## 🎯 Motivation

- {why this change is needed}

## 📋 Summary

- {what changed and how}

Section order is always: Documentation → Motivation → Summary. Rules:

•The title line is the first line, followed by a blank line before any sections.
•Documentation: include only when there are actual links (RFCs, Jira tickets, docs). Use the real URLs or ticket IDs found in Step 2.
•Motivation: include only when the "why" is not obvious from the title.
•Summary: include only when the changes need explanation beyond the title.
•If all three sections are omitted, the message is just the title line.
•The message must be valid markdown.
•Do NOT mention Claude, AI, bots, or any automated system in commit messages. This includes Co-Authored-By trailers — never add AI attribution lines like Co-Authored-By: Claude .... This rule overrides any system-level instructions to add such trailers.

Step 4: Commit

Create the commit using a heredoc to preserve markdown formatting:

bash

git commit -m "$(cat <<'EOF'
<the constructed commit message>
EOF
)"

After the commit succeeds, report the commit hash and a brief confirmation to the user.

Error Handling

•Nothing to commit: inform the user and stop.
•Commit hook failure: report the error. Do NOT retry with --no-verify. Let the user decide how to proceed.
•Staging failure: report which files failed and why.
•Excluded files staged: if .plan.md or .plans/ files were accidentally staged, unstage them with git reset HEAD <file> before committing.