checkpoint

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):

• {{BRANCH_PROD}} {{#if BRANCH_DEV}}
• {{BRANCH_DEV}} {{/if}} {{#if BRANCH_TEST}}
• {{BRANCH_TEST}} {{/if}}

If the current branch matches any of the above, abort immediately and say:

"You are on <branch>. /checkpoint must 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 in git log.
• If $ARGUMENTS is provided, use it as <message> (e.g. WIP: add auth middleware).
• If $ARGUMENTS is empty, auto-generate from the diff summary (e.g. WIP: update auth.ts, add login tests). Keep it under 72 characters.
• Do not commit .env files, secrets, or build artifacts. If git status shows such files, add them to .gitignore or 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-review when 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 {{CHECK_CMD}} — checkpoints are not quality gates.
• Do not prompt for confirmation — /checkpoint is a quick save, not a ceremony.