spec-checkpoint

Checkpoint Commit

Create a checkpoint commit that captures all current changes — but only after the code passes lint, type check, and build.

Instructions

Step 1: Analyze Changes

Run these commands to understand the full picture:

1. git status — see all tracked and untracked files
2. git diff — see detailed changes in tracked files
3. git diff --cached — see already-staged changes
4. git log -5 --oneline — understand this repo's commit message style

Step 2: Quality Checks

Run all three checks. If any fail, fix the issues before proceeding — do not skip or ignore failures.

1. npm run lint — fix any lint errors
2. npm run type-check — fix any type errors (if the script doesn't exist, try npx tsc --noEmit)
3. npm run build — fix any build errors

Iterate until all three pass cleanly. Only then move to the next step.

Step 3: Stage Everything

Stage all changes — tracked modifications, deletions, and new untracked files:

git add -A

Then review git status again. If anything staged looks like it could hold secrets — .env*, *.pem, *_rsa, credentials.json, secrets.*, or an unfamiliar filename that might contain an API key — unstage it (git restore --staged <file>) and tell the user what was excluded and why, rather than committing it silently. Don't rely on the filename alone for anything you don't recognize; skim its diff if you're unsure.

Step 4: Craft the Commit Message

Write a commit message following the project's existing conventions (observed from git log). Structure:

• First line: clear, concise summary in imperative mood (50-72 chars)
  • Use conventional commit prefixes where the project uses them: feat:, fix:, refactor:, docs:, chore:, etc.
• Body (separated by blank line): a short TL;DR of the changes — 1-3 sentences max. No bullet lists, no file-by-file breakdowns, no lengthy explanations.
• Footer: co-author attribution, naming whichever agent/model is actually running this skill — never hardcode a specific vendor or model name, since this skill runs under many different hosts