| name | finish |
| description | Stage changed files and produce a conventional commit message for approval. Use after completing any unit of work — bug fix, refactor, or a ticket closed by /implement. |
Commits in this repo go through an explicit approval stop. /implement closes a
ticket with /code-review, then hands over here — it does not commit on its own.
Process
- Run
git status — identify changed, added, and deleted files
- Run
git diff (staged and unstaged) — read the actual changes in detail
- Exclude files that must not be committed:
.env*, build artifacts, scratch files, editor state
- Stage all relevant files with
git add. Never git add . or git add -A
- Determine the commit type from the changes:
feat — new feature or user-visible capabilityfix — bug fixrefactor — restructuring without behavior changedocs — documentation onlytest — adding or updating testschore — build, tooling, dependencies, configstyle — formatting, no logic changeperf — performance improvement
- Draft the commit message following the format below
⛔ STOP. Present the staged file list and the proposed commit message. Do not commit until explicitly approved.
Commit format
<type>(<scope>): <short summary, imperative mood, max 72 chars>
<One sentence that frames the overall change — what it adds or fixes
at a high level, and why it matters.>
- <Specific change — what was added/modified and the reasoning or
tradeoff behind the decision.>
- <Specific change — include method names, file paths, component names
when they clarify what was touched.>
- <Specific change — explain exclusions and edge cases explicitly:
"X is intentionally excluded because Y".>
<Footer — notable technical context that isn't obvious from the diff:
migration notes, performance tradeoffs, deliberate design decisions,
known limitations. Not required if there's nothing non-obvious.>
Rules for the message
- Summary line: imperative mood (
add, fix, remove, update), lowercase, no trailing period
- Scope: the domain or module most affected (
auth, security, payments, cart)
- Overview sentence: one sentence only — frames the "what and why" at the highest level
- Bullets: one per logical unit of change; name real identifiers (functions, files, endpoints); explain the why behind each decision, not just the what
- Explicit exclusions belong in the bullets: "X is intentionally excluded because Y"
- Footer: non-obvious context only — migration decisions, deliberate tradeoffs, known caveats
- If changes are unrelated, propose splitting into multiple commits
- Prose paragraphs instead of bullets are fine when the change is a single idea that needs
explaining rather than a list — match what recent commits on the branch do
Pushing is a separate action and needs its own consent.
