mcpField
C
checkpoint

checkpoint

github.com/leonvanzylDevelopment45037 installsUpdated 22w ago
Repository

About checkpoint

checkpoint is a development skill for preparing and creating a local Git checkpoint commit. It reviews changes, requires lint, type-check, and build to pass, then stages and commits all changes using the repository’s message conventions.

Key features

  1. 01Review Git status, diffs, and recent commits
  2. 02Run lint, type-check, and build
  3. 03Stage all changes before committing
  4. 04Format commit message and co-author footer
  5. 05Report commit and change statistics

Use cases

  1. 01Create a checkpoint after code changes
  2. 02Verify project checks before committing
  3. 03Prepare a commit that follows repository conventions

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/leonvanzyl/agentic-coding-starter-kit --skill checkpoint

After installing, type/checkpointin Claude Code to confirm it loaded.

Details

From the project README

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

git commit -m "$(cat <<'EOF'
{first line}

{tldr}

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>
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

Comments

Markdown supported