Commit

---
name: commit
description: Selectively stages and commits only the changes related to the current session, skipping unrelated modifications.
argument-hint: "[optional: commit message or description of what to commit]"
---

# Commit Agent

Commit only the changes you made in this session to the local branch. Ignore all other changes. **Do not ask for confirmation at any step — just classify, stage, commit, and report.**

## Step 1: Understand What Was Done

Gather context about what you implemented:
1. Check for plans in `./tmp/done-plans/` and `./tmp/ready-plans/` — if any exist, read them for file lists and feature descriptions.
2. If no plans exist, use the conversation history to understand what files you created or modified and why.
3. If `$ARGUMENTS` is provided and does NOT match the `type: description` commit message format, use it as additional context for what should be committed (it will be used for classification in Step 3, not as the commit message).

## Step 2: Inspect All Changes

1. Run `git status` to see all modified, added, and deleted files.
2. Run `git diff` (unstaged) and `git diff --cached` (staged) to see the actual changes. Treat both as a single pool of changes to classify.
3. If there are no changes at all, tell the user there is nothing to commit and stop.

## Step 3: Classify Changes

For each changed file (whether staged or unstaged), determine if it was changed **by you in this session** or not:

**Your changes** — include these:
- Files you explicitly created or edited during this conversation
- Files referenced in plans you implemented (done-plans or ready-plans)
- Supporting changes (imports, types, config) that are clearly tied to your work
- `./tmp/done-plans/` files and `./tmp/context.md` changes associated with your work

**Not your changes** — skip these entirely:
- Files you did not touch in this conversation
- Pre-existing modifications from before the session
- Changes from other agents or manual edits unrelated to your task
- Unrelated `./tmp/` files (research notes, other plans)

When in doubt, include the file rather than leaving it out.

If zero files are classified as yours, tell the user that no changes match this session's work and stop.

**Do not present the classification for confirmation. Proceed directly to staging.**

## Step 4: Stage and Verify

1. `git add <specific files>` — only the files you changed. **Never** `git add .` or `git add -A`.
2. Review the staged diff (`git diff --cached`) for secrets or credentials:
   - API keys, tokens, passwords
   - .env files or credential files
   - Private keys or certificates
3. If secrets are found, **warn the user**, unstage the offending files, and ask how to proceed. Do not commit files containing secrets.

## Step 5: Create the Commit

Do not ask for confirmation. Just create the commit.

1. Write a commit message:
   - If `$ARGUMENTS` matches the `type: description` format (e.g., `feat: add commit skill`), use it verbatim as the commit message.
   - Otherwise, derive a message from the work context.
   - Format: `type: short description` (feat, fix, refactor, docs, chore). Under 72 characters. Imperative mood.
   - Add a body with bullet points if the commit covers multiple logical changes.
2. Create the commit to the local branch. Do not push.

## Step 6: Report

Present the result. Only suggest `/commit` again if there are uncommitted files remaining.

```
Committed: <short sha> <commit message>

Files included:
  - <file list>

Files left uncommitted:
  - <file list, or "none">

Next steps:
  - `/prepare-pr` — Rebase, build, and open a PR
```