TL;DR
What It Does
Creates a lightweight save point during your session without interrupting your workflow. It writes a partial handoff to your chat history file and creates a git commit for crash protection.
How It Works
The AI captures a snapshot of your session progress so far — what you have accomplished, which files were touched, and your current priorities. It writes this as a partial handoff to your chat history file (or updates an existing partial if one already exists from an earlier checkpoint). A lightweight validation confirms the checkpoint data matches actual git state. Then it creates a git commit so the checkpoint is recoverable even if the session ends unexpectedly.
What To Expect
A quick save — typically under a minute. The AI writes the checkpoint, validates it, commits, and confirms. Your workflow continues immediately afterward. The checkpoint is marked as “PARTIAL — SESSION IN PROGRESS” and will be updated or replaced by the full handoff (CWK-002) at session end.
Best Results When You
Use checkpoints after completing a significant piece of work mid-session, before attempting a risky operation, or when the CRAFT Operations Manager warns about token usage. The more frequently you checkpoint, the less context is at risk if something goes wrong.
Difficulty
Beginner — you can request a checkpoint at any time, or it triggers automatically based on token thresholds or significant file changes.
How To Start
This recipe can be triggered three ways: you request it manually, the CRAFT Operations Manager triggers it when token usage enters the warning zone, or it auto-triggers after significant file modifications. You can also invoke it directly.
STEP 1Request a Checkpoint
Tell the AI to save a mid-session checkpoint. The trigger parameter is usually set automatically based on how the checkpoint was initiated.
Available parameters
-
trigger
· string · optional · default: user_request
What triggered the checkpoint. Options: user_request (you asked for a save), token_threshold (COM detected warning zone token usage), post_modification (significant file changes just completed).
Example invocations
Manual checkpoint
#H->AI::Directive: (Create mid-session checkpoint)
Checkpoint after big changes
#H->AI::Directive: (Create mid-session checkpoint, trigger post_modification)
STEP 2Continue Working
The checkpoint completes automatically. The AI writes the partial handoff, validates it, creates a git commit, and confirms. Your workflow continues immediately — no further action needed.
Usage Examples
Two scenarios showing mid-session checkpoints — one triggered manually and one triggered automatically by the Operations Manager.
Example 1 · Manual checkpoint after completing a task
User:#H->AI::Directive: (Create mid-session checkpoint)
AI:Assessing session state. 8 files modified, 2 created since session start. No existing partial handoff found — creating new checkpoint. Writing to chat history. Validation: files match git status, accomplishments grounded. Git commit: b4e2a91. Checkpoint saved. Session can continue.
User:Great, let’s move on to the next recipe.
[Session continues with checkpoint safely committed]
Example 2 · COM-triggered checkpoint at token warning
AI:Token usage has entered the WARNING zone (estimated 70%). Creating automatic checkpoint.
AI:Updating existing partial handoff with latest accomplishments. 3 new files since last checkpoint. Validation passed. Git commit: c7f8d32. Checkpoint saved. Consider finalizing the session soon with a full handoff (CWK-002).
User:I’ll wrap up this recipe first, then do the handoff.
[Session continues with safety net in place]
How AI Reads This Recipe
When this recipe is triggered, the AI acts as a quick-save mechanism that preserves session state without disrupting workflow. The AI should:
- ASSESS current session state: gather accomplishments since last checkpoint or session init, list files created or modified, identify current work-in-progress task, and estimate token usage zone.
- CHECK for an existing partial handoff in the chat history file. If one exists (marked “PARTIAL — SESSION IN PROGRESS”), switch to update mode — append new accomplishments and files rather than creating a new entry.
- WRITE the checkpoint to the chat history file. For a new checkpoint, create a minimal partial handoff with session context, brief summary, accomplishments, files touched, deferred items, and current priorities. For an update, modify the existing partial in place.
- RUN lightweight validation with 2 questions: verify files touched match git status, and verify accomplishments are grounded in observable session activity. Correct any discrepancies before commit.
- CREATE a git commit staging the chat history and any other modified files. Do not push to GitHub — checkpoints stay local.
- CONFIRM completion with commit hash and checkpoint mode (create or update). If triggered by token threshold, add a warning to consider a full handoff soon.
The AI should keep checkpoints fast — under a minute. Do not prompt the user for review of checkpoint content. The partial handoff is a safety net, not a deliverable. It will be replaced or superseded by the full CWK-002 handoff at session end.
When to Use This Recipe
Use this recipe when you:
- Have completed a significant piece of work and want to save progress before moving on.
- Are about to attempt something risky (major file restructure, experimental changes) and want a recovery point.
- See the Operations Manager warning about token usage approaching limits.
- Want periodic safety saves during a long session.
Do not use this recipe when:
You are at the end of your session and ready to close. Use CWK-002 (Cowork Direct Handoff) instead — it creates a complete handoff with full validation, Lessons Learned capture, and proper session close metadata. Checkpoints are mid-session saves, not session-ending artifacts.
Recipe FAQ
Q.Does a checkpoint interrupt my workflow?
No. The checkpoint runs quickly (under a minute) and requires no input from you. The AI saves progress and immediately returns to whatever you were working on.
Q.What happens if I never do a full handoff after a checkpoint?
The partial handoff remains in your chat history file marked as “PARTIAL — SESSION IN PROGRESS.” The next session’s initialization (CWK-001) will detect it and use whatever context it contains. A full handoff is always better, but the checkpoint ensures some context survives an unexpected session end.
Q.Can I have multiple checkpoints in one session?
Yes. The second checkpoint updates the first rather than creating a new entry. The partial handoff accumulates accomplishments and file changes across all checkpoints in the session.
Q.Does the checkpoint push to GitHub?
No. Checkpoints create local git commits only. Pushing happens at session end via CWK-002 (if requested) or CWK-002a (device switch). This keeps checkpoints fast and avoids unnecessary network operations.
Q.How does the lightweight validation compare to the full validation in CWK-002?
The checkpoint runs 2 verification questions (files match git status, accomplishments grounded in activity) versus the full 5 questions in CWK-002. This keeps the checkpoint fast while still catching the most common data accuracy issues.
Version History
Changes to this recipe over time. Most recent first.
v1.01a
2026-03-01
Added lightweight Fernand validation (Step 3b). Runs 2 verification questions instead of the full 5 from CWK-002, checking files touched against git status and accomplishment grounding against session activity. Includes CWK-024 verification gate integration.
v1.00a
2026-02-28
Initial release. Lightweight mid-session save with partial handoff to chat history, create-or-update logic for existing partials, git commit for crash protection, COM token threshold trigger support.