commit

Commit

Save your work, update documentation, and keep the changelog current — all in one command.

Variables

message: $ARGUMENTS (optional — override commit message, or leave blank for auto-generated)

---

Instructions

You are committing changes to the workspace. This command does three things:

1. Creates a clean Git commit with a structured message
2. Checks if any technical documentation needs creating or updating
3. Updates HISTORY.md with what was done

Follow this workflow exactly.

Step 1: Understand What Changed

Run git diff HEAD to see all changes (staged and unstaged). Also run git status to see untracked files.

Review the changes and understand what was done. Summarize it mentally — you'll need this for the commit message, doc check, and changelog.

Step 1.5: Knowledge Capture Check (Auto-Capture Hook)

Before staging, ask: "Did this session produce a significant decision or learning worth keeping?"

A decision worth keeping: a choice was made that could be questioned later, sets a pattern, or eliminates an alternative. A learning worth keeping: something worked better than expected, something failed and revealed why, a pattern emerged that should be reused or avoided.

If yes:

1. Create a file in knowledge/decisions/ or knowledge/learnings/ using the template at _template.md
2. Name it YYYY-MM-DD-short-description.md
3. Fill out the template — this takes 2–3 minutes and compounds over sessions

If no: proceed to Step 2.

This is the Auto-Capture hook — the mechanism that ensures the system never forgets.

Step 2: Stage Changes

Stage the relevant changed files. Prefer staging specific files by name rather than git add -A, to avoid accidentally committing sensitive files.

Never stage:

• .env or any credential files
• data/*.db or data/*.db-* (database files)
• __pycache__/ or .venv/
• Any file that should be gitignored

If in doubt, ask the user: "I'm about to stage these files: {list}. Look good?"