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: ```bash git add -A ``` ### 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 ### Step 5: Commit Create the commit using a heredoc for proper formatting: ```bash git commit -m "$(cat <<'EOF' {first line} {tldr} Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> EOF )" ``` ### Step 6: Report Display: - The commit hash and message summary - Files changed count - Insertions/deletions summary ## Important - Stage and commit everything — do not skip files unless they are clearly sensitive (`.env`, credentials) - If the repo has no git history, run `git init` first - All quality checks (lint, type-check, build) MUST pass before committing — fix issues, don't skip them - Keep the commit body short — a TL;DR, not an essay - Follow the project's existing commit conventions (check the log first) - Do not push — only commit locally