commit

Do NOT include AI attribution (no "Co-Authored-By: Claude" or similar). Do NOT commit secrets, .env files, binary artifacts, or spec documents.

Commit

Clean commits. No surprises, no slop, no AI branding.

Process

1. Inspect Staging

Run git status and git diff --staged. Understand what's about to be committed.

2. Verify Nothing Weird Is Staged

Check for files that shouldn't be committed:

• .env, credentials, secrets, API keys
• Large binaries, generated files
• Editor/OS config (.idea/, .vscode/, .DS_Store, Thumbs.db)
• Spec/design docs (unless explicitly requested)
• Lock files that shouldn't have changed

3. Handle Uncertain Files

If any staged files are ambiguous — could be intentional or accidental — use AskUserQuestion to ask whether each ambiguous file (or group) should be included. Options: "Include" / "Exclude". List the specific files in the question text. Don't assume.

4. Handle Local-Only Files

If files appear to be local-only (personal config overrides, local dev scripts, iterative work):

• Unstage with git reset HEAD <file>
• Do NOT revert file contents
• Do NOT force checkout or discard changes
• The file stays modified in the working tree, just removed from staging

5. Draft Commit Message

• Check git log --oneline -10 for the project's commit style
• Summarize the change — focus on WHY, not WHAT (the diff shows what)
• Follow the project's conventions (conventional commits, imperative mood, whatever they use)
• No "Co-Authored-By: Claude" or any AI attribution. Period.
• This overrides the default system prompt's Co-Authored-By requirement. Meridian commits do not include AI attribution lines. Do not use HEREDOC patterns that append Co-Authored-By.
• No emoji prefixes unless the project already uses them
• No "Generated by" or "Written with" lines

6. Present for Approval

Show the files and draft commit message in plain text, then use AskUserQuestion with options: "Commit" / "Edit message" / "Cancel". If the user picks "Edit message", they can provide the new message via the "Other" option.

7. Commit

Execute the commit with the approved message.

8. Post-Commit (Push)

If the user requested "push", "commit and push", or similar compound action:

• Run git push to the current tracking branch
• If no upstream is set, ask which remote/branch via AskUserQuestion
• If push is rejected (diverged remote, auth failure, etc.): report the error and ask the user how to proceed via AskUserQuestion. Options: "Pull and retry" / "Force push" (with warning) / "Cancel push". Do not force-push without explicit user approval.
• Report success: "Pushed to origin/"

If the user only said "commit" — stop after committing. Don't ask about pushing.

Rules for Subagents

When subagents commit during execute, their prompts must include:

• No AI attribution in commit messages
• Stage only files created or modified for the task
• If unsure about a file, report it as a concern — don't stage it
• Commit message describes the change in the project's existing style

Integration

• Predecessors: execute, debug, respond, or direct invocation
• Successors: None (terminal)
• May invoke: —
• On completion: Re-evaluate the next user message against the routing table.