commitlisted

# Commit The history is the audit log for what an agent did. Months from now someone runs `git blame` on a line nobody remembers writing, and the commit message is the only record of why it's there. Inside `/ship` it matters sooner: the `/diff-explainer` step never saw the session that wrote the code. It gets the SPEC, the step reports, and these commits, and it won't annotate a decision nobody wrote down. So a message's job is what `/diff-explainer` does for a whole branch, for one commit: the why, the risks, the tradeoffs, and what got tried and thrown away. The diff already shows what changed. An argument is context ("addressing review feedback", "the migration is risky"), never the literal message. Don't stop to ask for approval. Being asked to commit means make the call, then report it. ## 1. See what's there ```bash git status --porcelain -uall git diff git diff --staged git log --oneline -15 ``` Nothing to commit? Say so and stop. Never make an empty commit. ## 2. Commit only what you made The tree can hold more than your work: a file the user was editing, a scratch script, a `.env` with credentials, a log someone forgot. Commit what this session produced. Leave the rest alone and name it in your report, so it doesn't look like an oversight. Can't tell if a change is yours? It isn't. Leaving it out costs a follow-up commit. Putting it in ships someone else's half-finished work under your name. Never commit anything that looks like a secret, even if you made it