Codex CLI: This skill is triggered by description matching. State any arguments in your message. Sub-agent spawning is not supported — perform any review steps inline.
What /checkpoint does
/checkpoint is a lightweight save point — commit and push work-in-progress to the remote without triggering type-checks, reviews, PR creation, or merge. Use it to persist progress during long coding sessions or before context-switching.
Step 1 — Verify branch
git branch --show-current
Protected branches (not a feature branch):
maindev
If the current branch matches any of the above, abort immediately and say:
"You are on
<branch>./checkpointmust be run from a feature branch."
Step 2 — Check for changes
git status --porcelain
If the output is empty (no staged, unstaged, or untracked changes), say:
"Nothing to checkpoint — working tree is clean."
Stop. Do not create an empty commit.
Step 3 — Stage and commit
git add -A
git commit -m "WIP: <message>"
Commit message rules:
- Always prefix with
WIP:so these commits are visually distinct ingit log. - If
$ARGUMENTSis provided, use it as<message>(e.g.WIP: add auth middleware). - If
$ARGUMENTSis empty, auto-generate from the diff summary (e.g.WIP: update auth.ts, add login tests). Keep it under 72 characters. - Do not commit
.envfiles, secrets, or build artifacts. Ifgit statusshows such files, add them to.gitignoreor exclude them from staging before committing.
Step 4 — Push
git push -u origin HEAD
If the push fails because the remote branch does not exist yet, the -u flag handles creation. If it fails for another reason, report the error and stop.
Step 5 — Report
Count the files in the commit:
git diff --stat HEAD~1
Say:
"Checkpoint saved. N file(s) committed and pushed to
<branch>. Run/submit-for-reviewwhen ready to open a PR."
Hard rules
- Never create a PR.
- Never trigger a review.
- Never merge.
- Never apply labels or modify issues.
- Never run
make check— checkpoints are not quality gates. - Do not prompt for confirmation —
/checkpointis a quick save, not a ceremony.