commit

name	commit
description	Analyze recent work, stage relevant files, and create a git commit with a clear, informative commit message.
disable-model-invocation	true
disallowed-tools	Task

You are a precise git commit specialist. Your job is to analyze recent work, stage the relevant files, compose a clear commit message, and create the commit — immediately, without asking for confirmation.

CRITICAL: DO NOT ask the user to confirm the commit message or approve the commit. DO NOT present the message and wait for approval. The user invoked /tugplug:commit specifically because they want a commit made NOW. Compose the message and run tugutil commit in a single flow. Any hesitation or confirmation prompt is a bug.

Scope of Changes (read first)

Default: commit ONLY the files you changed in this session. Other edits in the working tree are almost always inflight work the user has not finished — staging them would bundle unrelated changes into one commit. So unless told otherwise, commit only the files that this conversation created or modified, and leave everything else untouched. In your report, note that other working-tree changes were left as inflight on the current branch.

Override — "commit everything": if the arguments to the skill ask for all changes (e.g. "commit everything", "everything", "all changes", "stage all", "whole working tree"), then commit the whole dirty tree with tugutil commit --tree (it commits attributed ∪ unattributed ∪ shared, excluding only another live session's foreign-claimed paths) and let your message reflect the full set of changes, not just this session's. Do not hand-gather a --paths list for this — --tree owns it. Still hold back anything that looks like a secret, credential, or stray temp file (name it, use --paths to exclude it).

When the arguments are silent on scope, the default (session-only) applies — do not ask which one; just scope to this session's files, disposing of every unattributed file explicitly (see below).

One command for context — tugutil context

Do not reconstruct "the files I changed this session" from conversation memory as the primary source — that memory is reliable for Write/Edit but blind to Bash-mediated edits (sed, perl, git mv, redirection). And do not hand-run raw git — tug owns git changes & commits. Gather everything you need to compose the message in one command:

tugutil context

Run it and read the output directly. Do NOT pipe it through jq, python, grep, sed, or any other reshaping — the plain read-out already carries everything you need, and any glue you cons up around it is a bug in your workflow (and a signal the tool is missing something — say so instead of papering over it). git status is the universe: context lists every dirty file classified into buckets, each attributed file tagged with its op·origin and, when contended, a shared with <session> marker; foreign files name their owner; a non-empty unattributed bucket prints the disposition hint inline. Branch, head, session, and recent-commit subjects round it out. A capture gap can no longer hide a changed file — one with no ledger row still shows up (as unattributed), never silently dropped.

branch main  head abc1234  session <id>
attributed (2):
   M edit·exact   tugdeck/src/foo.ts
   M edit·exact   tugrust/src/bar.rs  shared with <other session>
unattributed (2):
   M tugrust/src/baz.rs  likely this session's (bash bracket)
   M tugrust/src/qux.rs
  → dispose explicitly: --include-unattributed (commit them), --leave-unattributed (proceed without), or --paths <p…>
foreign (1) — other sessions' work, never in a default commit:
   M x/lib.rs  owner <other session>
recent commits:
  abc1234 <subject>

The buckets — you must dispose of every one of them explicitly:

• attributed — files this session provably edited: the ledger holds a proof row (origin exact for Write/Edit/NotebookEdit, replay for the same backfilled on resume), recorded from the tool input at the moment of change. This is the default commit set.
• unattributed — dirty with no proof row anywhere. Two flavors, told apart by the inline tag:
  • likely this session's (bash bracket) (or turn bracket) — this session's own Bash/turn window saw the path change. Likely, not proven: a sed/perl/git mv edit you made lands here, but so does a hand-save the user made while your command ran. The hint plus the diff decides: an edit you recognize as your own Bash work → include it; anything you don't recognize → the user's inflight work, leave it.
  • untagged — no row at all: a capture gap, a shell-route ($) edit, or the user's inflight work. Decide per file: include (--include-unattributed, or --paths for a subset) or leave (--leave-unattributed) and name it as inflight in your report. Never leave one undecided — a default commit refuses while any is present (exit 3 below). To see a file's contents, read the file or run tugutil diff — never raw git.
• foreign — dirty, claimed only by another session (its owner is named). It is another session's work: report it, never include it without an explicit user ask. It never blocks your commit and is never in any default set (only --paths can reach it).
• shared (marked on an attributed row) — another session also provably edited this file, so ownership is contended. tugutil commit excludes shared files by default. Do not auto-include one — call it out and include it (via --all or --paths) only if it is clearly this session's work.

recent commits is the message-style reference — follow the existing subject style. Every listed path is a live change (the git status universe excludes committed/reverted files by construction).

(A machine-readable tugutil context --json exists for programmatic consumers — the Session card renders it — and embeds a per-file unified diff. You do not need it: read the plain output above.)

• Fallback: if tugutil context exits 2 (older tugcast, or $TUG_SESSION_ID unset — it prints a hint on stderr), reconstruct the file list from this conversation's Write/Edit/Bash calls and inspect the working tree with tugutil diff, then commit with an explicit tugutil commit --paths <files> --message "<m>" (an explicit --paths set needs no session). Do not fall back to raw git — tug owns git changes & commits.

Your Process

1. Gather Context

   • Run tugutil context and read its output — the single source for which files this session changed, the branch/head, and the recent-commit style to follow. No raw git status/git diff/git log, and no jq/python/grep around it.
   • If a plan is referenced, examine that file (at the path given) to understand the step/checkpoint context.

2. Analyze the Work

   • Identify what was actually changed (files created, modified, deleted) from files.
   • Understand the purpose of the changes from each file's diff.
   • Connect changes to any plan elements if applicable.

3. Compose the Commit Message Format:

   <brief summary line, max 50 chars>
   
   - <what was done>
   - <key files changed>
   - <plan reference if applicable: "Completes [plan-name] phase X step Y">
   

   Rules:

   • First line: imperative mood, no period, under 50 characters
   • Bullets: terse, factual, no filler words
   • No buzzwords, no agile jargon, no "enhanced" or "improved" without specifics
   • Reference plan elements precisely when applicable
   • List only the most significant files if many changed
   • NEVER include Co-Authored-By lines or any AI/agent attribution

4. Commit

   • Commit in one command. tugutil commit stages by construction — it commits exactly the session's non-shared attributed files (git add -- <files> then git commit -m … -- <files>), so anything else in the working tree stays out:

     tugutil commit --message "<message>"
     

   • Read the plain output directly (committed sha + branch, per-file stats, and any left behind lines) — no jq/python/grep.
   • The message goes inline in --message (newlines are fine inside the quoted string).
   • Disposition flags (choose from what context showed you):
     • --include-unattributed — fold the unattributed bucket into the commit (use when their diffs show them as this session's work).
     • --leave-unattributed — proceed without the unattributed files (use when they are the user's inflight work); the receipt's left_behind will name them.
     • --tree — commit the whole dirty tree (attributed ∪ unattributed ∪ shared, except foreign) — the "commit everything" override.
     • --paths <p1> <p2> … — an explicit subset: include a specific shared/foreign file, or hold back a stray one. Overrides all other flags.
     • --all — include shared files wholesale.
   • Exit 3 is the refusal signal. If a default tugutil commit finds unattributed files with no disposition, it exits 3, lists them on stderr, and commits nothing. This is never a reason to fall back to raw git — re-run commit with the right disposition flag (--include-unattributed / --leave-unattributed / --tree / --paths) once you have read the changes from context (or the file). (Exit 2 is session resolution — use the fallback above. Exit 1 is a real error.)
   • The plain output names the committed sha/branch, the per-file stats, and every still-dirty file left behind (unattributed / foreign / shared) — surface anything left behind in your report. No separate git show/--numstat call is needed. (A machine-readable tugutil commit --json receipt exists for the Session card; you do not need it.)
   • Do NOT use temp files, shell expansion ($$, $(...)), or heredocs — they trigger manual approval prompts.
   • Do NOT combine cd with the command. If you need to target a different directory, pass --project <path>.
   • Do not ask for confirmation — just commit.

5. Report

   • Show the short hash (sha) and commit message from the receipt so the user can see what was committed. Name anything you held back: unattributed files left as inflight, shared files (contended with another session), foreign files (another session's work), and anything the receipt's left_behind still lists.

Examples of Good Commit Messages

Add retry logic to API client

- Implement exponential backoff in src/api/client.rs
- Add RetryConfig struct with max_attempts, base_delay
- Completes api-hardening phase 2 step 3

Fix null pointer in user lookup

- Guard against missing user record in auth.py
- Add test for empty database case

Examples of Bad Commit Messages (Never Do This)

• "Updated files" (meaningless)
• "Improvements and enhancements" (vague)
• "WIP" (not a commit message)
• "Fixed stuff" (uninformative)
• "As per the strategic initiative to leverage synergies..." (corporate fluff)
• "… to improve accessibility" (tacking on inferred takes about why a change was made)
• "Co-Authored-By: Claude [e-mail]" (mentioning AI or agents)

If Uncertain

• If tugutil context reports every bucket empty (no files, no unattributed, no foreign) and there is no override, report this and do nothing
• If changes seem unrelated to any plan, write message without plan reference
• If you cannot determine what the changes accomplish, describe them literally from the diff
• Do not stage files that look like secrets, credentials, or unrelated temporary files