Commit

Commit Changes

You are tasked with creating git commits for repository changes.

Input

$ARGUMENTS — optional commit message hint, optionally with --baseline <path> (a workflow's run-start snapshot of paths that were already dirty before the run began). Peel the --baseline flag first; the remainder (if any) is the message hint. Empty/literal → infer from history and git diff.

Metadata

node "${SKILL_DIR}/../_shared/git-changes.mjs"
echo "---recent-subjects---"
git log --pretty=%s -n 20 2>/dev/null || true

---recent-subjects--- — up to 20 most recent commit subject lines, used in Step 2 to match the repository's existing commit-message style. Empty on a no-HEAD initial repo.

When --baseline <path> was provided, the Metadata block above was rendered WITHOUT the baseline (render-time substitution cannot capture $ARGUMENTS — same reason code-review's scope helper is LLM-invoked). Before anything else, re-run the snapshot with the baseline threaded and use ITS output as the authoritative ---status--- / ---diffstat--- for the rest of this skill:

node "${SKILL_DIR}/../_shared/git-changes.mjs" --baseline <path>

---pre-existing (do NOT commit — dirty before this run)--- — present in that re-run's output when some listed files were already dirty before the run began. These are out of scope: they are not this run's work. Never git add a path in this section — a workflow commits only the changes it produced. The re-run's ---status--- block already excludes them; they are shown purely so you know they exist and must be left uncommitted.

Context:

• In-session: If there's conversation history, use it to understand what was built/changed
• Standalone: If no context available, rely entirely on git state and file inspection

Process:

0. Check git availability:

   • If in_repo: in the Metadata block is no, tell the user: "This directory is not a git repository. Run git init to initialize one." Stop — do not proceed.

1. Think about what changed:

   • If in-session: Review the conversation history to understand what was accomplished.
   • The Metadata block gives you the file list and per-file diffstat (insertions/deletions). For files with a small diffstat (≲5 lines), the line counts alone are enough to write the message — skip git diff. Run git diff <path> only for files where the change is large or the intent isn't obvious from filename + line counts.
   • For untracked directories shown in status (e.g. ?? path/), assume their contents are the change unless the directory has many files; do NOT cat/head files to verify obvious purpose.
   • Consider whether changes should be one commit or multiple logical commits.

2. Plan your commit(s):

   • Identify which files belong together
   • Draft clear, descriptive commit messages
   • Use imperative mood in commit messages
   • Match the subject style observed in ---recent-subjects--- — same prefix convention (e.g. feat: / fix(scope): / docs: for Conventional Commits, gitmoji, bare sentence-case, ticket-prefixed, etc.), same length budget, same casing. If the sample is empty (initial repo) or mixed, default to imperative sentence-case with no prefix.
   • Focus on why the changes were made, not just what
   • Check for sensitive information (API keys, credentials) before committing

3. Present your plan to the user:

   • List the files you plan to add for each commit
   • Show the commit message(s) you'll use
   • Use the ask_user_question tool to confirm the commit plan. Question: "{N} commit(s) with {M} files. Proceed?". Header: "Commit". Options: "Commit (Recommended)" (Create the commit(s) as planned); "Adjust" (Change the grouping or commit messages); "Review files" (Show me the full diff before committing).
     • Header is capped at ≤16 characters (MAX_HEADER_LENGTH = 16 — longer values are rejected).

4. Execute upon confirmation:

   • Use git add with specific files (never use -A or .) — and stage only files from the ---status--- block. Any path under ---pre-existing (do NOT commit …)--- is out of scope: leave it dirty, never stage it.
   • Create commits with your planned messages
   • Show the result with git log --oneline -n X (where X = number of commits you just created)

Important:

• NEVER add co-author information or Claude attribution
• Commits should be authored solely by the user
• Do not include any "Generated with Claude" messages
• Do not add "Co-Authored-By" lines
• Write commit messages as if the user wrote them

Remember:

• Adapt your approach: use conversation context if available, otherwise infer from git state
• In-session: you have full context of what was done; Standalone: infer from git analysis
• Group related changes by purpose (feature, fix, refactor, docs)
• Keep commits atomic: one logical change per commit
• Split into multiple commits if: different features, mixing bugs with features, or unrelated concerns
• The user trusts your judgment - they asked you to commit