Commit

You are producing a copyable commit message for the user's latest changes. Do not run git commit — just output the message in a single fenced code block so the user can copy it.

Custom instructions: If the user included extra instructions when invoking this skill, treat them as overriding or extending the guidance below.

1. Figure out what changed

• First, rely on the conversation history. If you (or the user) made the changes earlier in this chat, you already know what was done and why — use that as the primary source.
• If the chat history doesn't cover the changes, inspect the working tree to understand the latest uncommitted changes:
  • git status for the file list
  • git diff (and git diff --staged) for the actual edits
• Consult .docs/backlog.md if it helps explain the intent behind the changes (e.g. a backlog item that was just completed).
• If the scope is still unclear after all of the above, ask the user before writing the message.

2. Check the commit convention

Before writing the message, make sure it matches the convention this project actually uses — don't assume Conventional Commits.

• A recorded decision wins outright. If .docs/commit-convention.md exists, follow it and skip to the next step — no re-analysis, no asking.
• Otherwise, look at recent history: git log -20 --no-merges --oneline.
  • Too little history (fewer than ~5 commits, e.g. a brand-new repo): default to Conventional Commits, write that default to .docs/commit-convention.md, and say so in one line.
  • A dominant pattern (Conventional Commits, a ticket/issue-ID prefix, gitmoji, plain imperative subjects with no prefix, or something else consistent across most of the sample): adopt it, write it to .docs/commit-convention.md, and tell the user in one line what you detected and that you're following it.
  • Mixed or ambiguous: ask the user once which convention to use, recommending Conventional Commits if they have no preference. Once they answer, write it to .docs/commit-convention.md and say plainly it's saved so you won't be asked again.
• .docs/commit-convention.md is shared with /merge and /push — whichever of the three runs first writes it, the others just read it.

3. Write the message

If .docs/commit-convention.md says something other than Conventional Commits, follow that format and skip the rest of this section. Otherwise, format:

<type>: changed this, added that, edited this, removed this

- more specific bullet about one change
- more specific bullet about another change
- ...

• Title line: follows Conventional Commits — <type>: <summary>, where type is one of feat, fix, docs, refactor, chore, style, test, perf, build, ci. Then a short comma-separated list of the main changes using plain verbs (added, changed, removed, edited, fixed). Keep it under ~100 characters when reasonable.

• Breaking changes: mark them, either with ! after the type (feat!: ...) or a BREAKING CHANGE: line in the body. This is the one detail that must not be skipped — it's what decides a major version.

• Body: a blank line, then bullet points going a bit deeper — one bullet per meaningful change. Keep each bullet short and concrete. Don't pad with obvious filler.

• Pick the <type> that best matches the dominant change. If truly mixed, chore or refactor are fine.

• Describe the "what" plainly. Only include a "why" if it's non-obvious and useful.

• Do not add footers, Co-Authored-By lines, emoji, or marketing language.

The type isn't decoration — /version reads these to work out the next Semantic Version: feat implies a minor bump, fix a patch, a breaking marker a major (minor while pre-1.0), and docs / chore / refactor / test / ci imply no release at all. Calling a feature chore hides it from the release; calling a refactor feat inflates the version. Pick the type that's true.

4. Output

• Print the commit message inside a single fenced code block so it's easy to copy.
• Do not run git commit, do not stage files, do not modify the repo.
• After the code block, optionally add one short line if something is worth flagging (e.g. "there are also unstaged changes in X you may want to include").