agentleFS
excattexcatt/superclaude-plusplus/skills/checkpoint/SKILL.md

checkpoint

Skill14 starsChanged 37 days agoMITView on GitHub

Save and restore work state with Git-based lightweight checkpoint system. Use before risky work, milestone completion, experimental changes. Keywords: checkpoint, save, restore, rollback, snapshot, backup, git, stash.

91 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use aside, spinoff and 9 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • TheKREATORSSkill

    aside

    Answer a quick side question without interrupting or losing context from the current task. Resume work automatically after answering.

    Also in 3 projects that use this

  • AhmedMerzaSkill

    spinoff

    After a branch is finished, harvest the work it made CHEAP — the helper you wrote that four other sites now hand-roll, the plumbing that turned a deferred feature small, the pattern that just split the codebase in two. Produces a follow-up backlog (0–3 candidates, feeding /issue), NEVER commits on the current branch. Invoke with /spinoff at the tail of the chain — after /fix-review has settled the review findings, before the MR merges — or when the user asks \"what else should we do while we're here / what did this unlock / anything to follow up on\". This is ship-check's optional twin — that finds what's MISSING and blocks the merge; this finds what's now CHEAP and blocks nothing. Restraint-gated: \"nothing spun off\" is the common and correct answer, and a finding that would have been equally valid before this branch is not a finding.

    Also in 3 projects that use this

  • TheKREATORSSkill

    instinct-export

    Export instincts from project/global scope to a file

    Also in 3 projects that use this

  • seek888Skill

    open-gstack-browser

    Launch GStack Browser — AI-controlled Chromium with the sidebar extension baked in. Opens a visible browser window where you can watch every action in real time. The sidebar shows a live activity feed and chat. Anti-bot stealth built in. Use when asked to "open gstack browser", "launch browser", "connect chrome", "open chrome", "real browser", "launch chrome", "side panel", or "control my browser". Voice triggers (speech-to-text aliases): "show me the browser".

    Also in 5 projects that use this

  • seek888Skill

    design-html

    Design finalization: generates production-quality Pretext-native HTML/CSS. Works with approved mockups from /design-shotgun, CEO plans from /plan-ceo-review, design review context from /plan-design-review, or from scratch with a user description. Text actually reflows, heights are computed, layouts are dynamic. 30KB overhead, zero deps. Smart API routing: picks the right Pretext patterns for each design type. Use when: "finalize this design", "turn this into HTML", "build me a page", "implement this design", or after any planning skill. Proactively suggest when user has approved a design or has a plan ready. (gstack) Voice triggers (speech-to-text aliases): "build the design", "code the mockup", "make it real".

    Also in 5 projects that use this

  • ayudaySkill

    setup-deploy

    Configure deployment settings for /land-and-deploy. Detects your deploy platform (Fly.io, Render, Vercel, Netlify, Heroku, GitHub Actions, custom), production URL, health check endpoints, and deploy status commands. Writes the configuration to CLAUDE.md so all future deploys are automatic. Use when: "setup deploy", "configure deployment", "set up land-and-deploy", "how do I deploy with gstack", "add deploy config".

    Also in 5 projects that use this

  • +2 more from TheKREATORS
  • +2 more from seek888

The file

We split this skill into the rules it gives an agent

8 rules. 0 are common, 7 are distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 85 edited versions we read keep these.

  • 7

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Core Principle: Always checkpoint before risky work → Safe experimentation → Rollback if needed

    line 19
  2. Distinctive:

    Before starting experimental changes

    line 23
  3. Distinctive:

    Before PR submission (save final state)

    line 25
  4. Distinctive:

    Verify current state is clean

    line 38
  5. Distinctive:

    Create stash or commit if changes exist

    line 39
  6. Distinctive:

    Action: Keep only the most recent 5 checkpoints, delete the rest

    line 150
  7. Very specific:

    Run /checkpoint clear when 5+ accumulate

    line 258
  8. Distinctive:

    Create checkpoints only in working states

    line 260

“Common” is measured: kept by at least 6 in 10 of the 85 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Dynamic Context

Current git state: !git log --oneline -5 2>/dev/null

Existing stashes: !git stash list 2>/dev/null || echo "No stashes"

Checkpoint Skill

Purpose

Save, compare, and restore work state when necessary using Git stash/commit-based lightweight checkpoint system.

Core Principle: Always checkpoint before risky work → Safe experimentation → Rollback if needed

Activation Triggers

  • Before risky refactoring
  • Before starting experimental changes
  • On major milestone completion
  • Before PR submission (save final state)
  • User explicit request: /checkpoint, checkpoint, save

Commands

Create Checkpoint

/checkpoint create <name>

Actions:

  1. Verify current state is clean
  2. Create stash or commit if changes exist
  3. Record in .claude/checkpoints.log
  4. Save timestamp and Git SHA

Example:

/checkpoint create before-auth-refactor

✅ Checkpoint Created
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Name:      before-auth-refactor
Time:      2025-01-26 14:30:22
SHA:       a1b2c3d
Files:     12 staged, 3 modified
Status:    Clean state saved
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Verify Against Checkpoint

/checkpoint verify <name>

Actions:

  1. Find saved checkpoint
  2. Compare with current state
  3. Report change metrics

Example:

/checkpoint verify before-auth-refactor

📊 Checkpoint Comparison
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Checkpoint:    before-auth-refactor
Created:       2025-01-26 14:30:22
Current SHA:   d4e5f6g

📁 Files Changed: 8
   ├─ src/auth/login.ts      (+45, -12)
   ├─ src/auth/middleware.ts (+23, -5)
   ├─ src/api/user.ts        (+15, -8)
   └─ ... 5 more files

📈 Test Coverage:
   Before: 78%
   After:  85% (+7%)

🧪 Tests:
   Before: 42 passed
   After:  47 passed (+5 new)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

List Checkpoints

/checkpoint list

Example:

/checkpoint list

📋 Saved Checkpoints
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Name                    Time                 SHA       Status
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
before-auth-refactor    2025-01-26 14:30    a1b2c3d   ← HEAD~3
feature-complete        2025-01-26 12:15    x7y8z9a   ← HEAD~8
initial-setup           2025-01-26 09:00    m4n5o6p   ← HEAD~15
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Total: 3 checkpoints

Restore Checkpoint

/checkpoint restore <name>

Actions:

  1. Backup current changes (auto stash)
  2. Restore to checkpoint
  3. Confirm restoration

Example:

/checkpoint restore before-auth-refactor

⚠️ Restore Confirmation
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
This will:
1. Stash current changes (auto-backup)
2. Reset to checkpoint: before-auth-refactor
3. You will lose: 8 file changes since checkpoint

Proceed? [y/N]

Clear Old Checkpoints

/checkpoint clear

Action: Keep only the most recent 5 checkpoints, delete the rest


Implementation Details

Checkpoint Log Format

.claude/checkpoints.log:

[2025-01-26T14:30:22] before-auth-refactor | SHA:a1b2c3d | stash@{0}
[2025-01-26T12:15:10] feature-complete | SHA:x7y8z9a | commit
[2025-01-26T09:00:05] initial-setup | SHA:m4n5o6p | commit

Git Commands Used

# Create checkpoint (commit-based)
git add -A
git commit -m "checkpoint: <name>"

# Create checkpoint (stash-based for uncommitted work)
git stash push -m "checkpoint: <name>"

# Verify
git diff <checkpoint-sha>..HEAD --stat

# Restore
git stash  # backup current
git checkout <checkpoint-sha>

# List
git log --oneline --grep="checkpoint:"

Workflow Integration

Typical Development Flow

/checkpoint create "start-feature"
    │
    ├─→ Implementation work
    │
    ├─→ /verify quick
    │
    ├─→ /checkpoint create "mid-feature"
    │
    ├─→ Risky refactoring
    │       │
    │       ├─→ Success → Continue
    │       │
    │       └─→ Failure → /checkpoint restore "mid-feature"
    │
    ├─→ /verify full
    │
    └─→ /checkpoint create "feature-complete"

With /verify

/checkpoint create "before-refactor"
... refactoring ...
/verify full
    │
    ├─→ ✅ Pass → Continue
    │
    └─→ ❌ Fail → /checkpoint restore "before-refactor"

With /feature-planner

Auto-checkpoint before each Phase:

Phase 1 start → /checkpoint create "phase-1-start"
Phase 1 complete → /checkpoint create "phase-1-complete"
Phase 2 start → /checkpoint create "phase-2-start"
...

Best Practices

Checkpoint Naming Rules

✅ Good:
- before-auth-refactor
- phase-2-complete
- pre-db-migration
- working-login-flow

❌ Bad:
- checkpoint1
- test
- temp
- asdf

Recommended Checkpoint Timing

SituationCheckpoint Name
Feature startstart-<feature>
Reached working stateworking-<feature>
Before risky changebefore-<change>
Phase completionphase-N-complete
Before PRpre-pr-<feature>

Checkpoint Management

  • Run /checkpoint clear when 5+ accumulate
  • Use meaningful names
  • Create checkpoints only in working states

Quick Reference

CommandDescription
/checkpoint create <name>Create checkpoint
/checkpoint verify <name>Compare with checkpoint
/checkpoint listList all checkpoints
/checkpoint restore <name>Restore to checkpoint
/checkpoint clearClean old checkpoints

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.