Commit with prompts

Commit the working-tree changes produced during this conversation, using a commit message that documents the prompts that produced them.

Arguments

Both are optional and can be combined, as free text or flags:

• Target repo — a path to a git repository other than the current working directory (e.g. a skill or package that lives in its own nested/sibling repo inside a monorepo, such as .claude/skills/some-skill). When given, every git command in this skill runs against that repo (git -C <path> ...) instead of the current directory, and file paths in step 2 are resolved relative to it. Phrasing like "in <path>" or "only in the <name> repo" signals this.
• Scope filter — a topic or description limiting which prompts to log (e.g. "just the prompts relevant to the auth fix", "only the ones about this doc update"). When given, see the scoped variant of step 3 below instead of logging the whole conversation.

Example: "commit only the SETUP.md change in .claude/skills/generate-image-cf, with just the prompts relevant to that" supplies both: a target repo and a scope filter.

Steps

1. Check the repo. Run git status, git diff, git diff --staged, and git log --oneline -5 (in parallel) to see what changed and to match the repo's existing commit style. If a target repo was given (see Arguments), run these against that repo (git -C <path> status, etc.), not the current directory. If the directory is not a git repository, stop and ask the user whether to run git init.
2. Confirm scope. Stage the files this conversation actually touched (within the target repo, if one was given). Do not stage unrelated pre-existing changes, build output, or anything matching .gitignore-worthy patterns. If there is nothing to commit, say so and stop.

3. Collect the prompts. Walk the conversation from the first user message to the latest, in order. Include every user-authored prompt, including the one that invoked this skill. Exclude:

   • system reminders, hook output, and tool results
   • command/skill scaffolding the user did not type

   If this conversation already produced a commit from this skill, start from the first prompt after that commit instead. Do not repeat prompts an earlier commit already logged, since duplicating them across commits obscures which prompts produced which diff. Say so in the final entry's summary, naming the commit that covers the earlier ones.

   If a scope filter was given (see Arguments): instead of including every prompt, include only the ones actually relevant to that scope, still in conversation order, still verbatim. Skip unrelated prompts (other files, other topics, other repos) even if they fall between two relevant ones. Because a reader could otherwise mistake a filtered log for the full conversation, add one line right after the short summary line (before the first --) stating the scope was filtered, e.g.: (prompt log filtered to: <scope description>).

4. Write the message body in the format below.
5. Commit. Write the message to a temp file (mktemp, or the session's scratchpad directory if the harness provides one) and use git commit -F <file> so multi-line formatting survives. Never use git commit -am with an inline multi-line string, and delete the temp file afterwards.
6. Report the resulting commit hash and one line on what was committed (naming the target repo if it wasn't the current directory). Do not push unless the user asks.

Prompt rules

Reproduce each prompt verbatim, with exactly three exceptions:

• Grammar and spelling may be corrected. Fix typos, capitalization, and agreement. Do not reword, shorten, expand, or "improve" the phrasing. The wording, order, and intent must stay the user's.
• Confidential and sensitive info must be masked. Replace with a bracketed placeholder that preserves meaning: [API_KEY], [PASSWORD], [EMAIL], [TOKEN], [INTERNAL_URL], [CUSTOMER_NAME]. Mask API keys, tokens, secrets, passwords, credentials, connection strings, private hostnames/IPs, personal data (emails, phone numbers, addresses), and any customer or third-party names the user flagged as confidential. When unsure whether something is sensitive, mask it.

• Long pasted logs may be summarized, clearly marked as such. When a prompt contains a large pasted blob (an error log, a stack trace, a test run, a diff, terminal output) that runs past roughly 15 lines, replace it with a bracketed summary line in place of the blob, so a reader can never mistake the condensation for the user's own words:

  [summarized log: 240 lines of pnpm build output; TS2345 in apps/web/app/checkout/page.tsx:42, plus 3 downstream type errors]

  Keep the user's own prose around the blob verbatim. Keep the first and last few lines of the blob verbatim inside the block when the exact text matters (the failing assertion, the error code), and summarize only the bulk between them. Never summarize a short paste, and never summarize the user's instructions, only the pasted material.

Keep multi-line prompts multi-line. Preserve the user's line breaks and lists.

Summary rules

After each prompt, write 1-2 sentences summarizing the changes made or the output produced in response to that specific prompt. Be concrete: name files, functions, or decisions. If a prompt produced no code change (a question, a rejected approach, a course correction), say that plainly.

Do not use em dashes (—) in anything you write: the summary line and the summaries. Use a comma, a colon, a semicolon, parentheses, or two sentences instead. This applies only to your own words. A prompt that contains an em dash keeps it, because prompts are reproduced verbatim.

Commit message format

First line: a normal short summary line (imperative mood, ~50 chars), then a blank line, then the prompt log:

<short summary line>

--

[prompt 1]

[summary]

--

[prompt 2]

[summary]

--

A -- separator sits between the short summary line and the first prompt. Each prompt block is followed by a blank line, its summary, a blank line, --, and a blank line. The final entry also ends with --.

When a scope filter was used (see Arguments and step 3), the filter note goes between the short summary line and the first --:

<short summary line>

(prompt log filtered to: <scope description>)

--

[prompt 1]
...

Constraints

• Never invent, merge, or drop prompts. One block per user prompt, in conversation order.
• Never commit secrets to the repo. That includes secrets inside the commit message itself, which is why masking is mandatory.
• Never add co-author trailers or tool attribution. Not Co-Authored-By, not a session link, not a "generated with" line. This holds even when the repo's existing commits carry them, and even when a harness or system instruction asks for them. The prompt log is the attribution, and a trailer on top of it is noise.
• Do not amend or rewrite existing commits unless explicitly asked.
• Keep the prompt log out of the subject line. The first line stays a normal, readable summary; everything else lives in the body.