Commit

Commit

Verify the gates, then commit. A commit is not a pull request, and a pull request is not a merge. This skill stops after the commit. It pushes and opens a pull request only with --pr or when the user asks, and it never merges — a merge happens only when the user explicitly says to merge that pull request (see "Merging" below). Reviewers such as Codex and Copilot comment after a pull request opens; merging before they report skips their review.

Steps

Step 0: Quality Gate (Pre-Commit)

Run before branching. For every changed .qmd, .tex, or .R file that has quality rubrics, run:

python3 scripts/quality_score.py <changed-file-paths>

• If any file scores below 80, halt and report the findings. The user must either fix the issues or explicitly override with phrases like "commit anyway" or "skip quality gate". Once ./scripts/install-hooks.sh has been run, .githooks/pre-commit re-runs the same ≥80 gate on the staged .qmd/.tex/.R files, so carry an approved override into Step 4 as SKIP_QUALITY_GATE=1 git commit ... and record the override reason in the commit message. That variable skips only the quality score; the backtest still runs. Never fall back to git commit --no-verify.
• If all files score 80+, continue.

Spawn the verifier agent (via the Agent tool with subagent_type=verifier) to run compilation/render checks on the changed files. Report pass/fail before committing.

Step 0b: Consistency Gate (Pre-Commit)

Runs unconditionally. The full backtest suite — all ten gates (surface-sync count claims like "18 agents, 61 skills, 37 rules, 11 hooks" and marked tables, skill integrity, model currency, links, spec conformance, staleness, repo hygiene, derived counts, ledger coverage, hook battery):

./scripts/backtest.sh

• Exit 0: all gates green — continue.
• Nonzero: at least one gate is red — print its output and halt. Fix, then re-run. Do not proceed past this gate on a red result, even with "commit anyway": a red gate is drift that the next reader inherits, and small count drift has repeatedly cost follow-up PRs.

Step 0c: Passport Check (Pre-Commit)

If the diff touches a manuscript (.tex/.qmd) that has a passport in quality_reports/passports/, any source_file a passport lists, or any file a claim declares as a display (its location:, or an appears_in path:), read that passport: a load-bearing claim with status: FAIL or STALE is a must-fix — halt, name the claim, and point at /audit-reproducibility (or the stale script) before committing. A touched display triggers the check for the same reason a touched script does: editing one artifact's copy of a number desynchronizes it from that number's other displays — the supplement or deck holding the same value was not necessarily updated in the same commit. Skip silently when no passport exists.

Step 1: Check current state

git status
git diff --stat
git log --oneline -5

Step 2: Create a branch (when on main)

Never commit directly to main. If the current branch is main, create one; if you are already on a feature branch, commit there.

git checkout -b <short-descriptive-branch-name>

Step 3: Stage files

Add specific files (never use git add -A):

git add <file1> <file2> ...

Do NOT stage .claude/settings.local.json or any files containing secrets.

Step 4: Commit with a descriptive message

If $ARGUMENTS is provided, use it as the commit message. Otherwise, analyze the staged changes and write a message that explains why, not just what.

The subject line states what is TRUE AFTER the commit — a plain sentence about behavior that a reader could go and test. "Fixed review feedback" and "Updated the checker" narrate your afternoon and tell a reader nothing; "The parity gate refuses a fixture whose hash is unregistered" is a claim they can check against the code. Process narration — which review round it came from, who asked, how many attempts it took — belongs in the body if it belongs anywhere. The body still carries the why; the subject carries the claim.

git commit -m "$(cat <<'EOF'
<commit message here>
EOF
)"

Step 5: Push and open a pull request — only with --pr or when the user asks

Without --pr, and without the user asking for a pull request, skip this step: the commit stays local and the report says so.

git push -u origin <branch-name>
gh pr create --title "<short title>" --body "$(cat <<'EOF'
## Summary
<1-3 bullet points>

## Changed defaults
<"None", or each default a forker will notice changing: a setting, a threshold, a hook that now fires, a path that moved>

## Test plan
<checklist>

🤖 Generated with [Claude Code](https://claude.com/claude-code)
EOF
)"

Step 6: Report

Report the commit (hash and subject), the branch, and — if a pull request was opened — its URL. Say plainly that nothing was merged.