Checkpoint review
Insert a short review pause between rounds so work can continue, stop, or hand off with better discipline.
Canonical skill profile. This page is generated from the repository contract. The linked
SKILL.mdremains the source of authority.
| Category | Version | Owner |
|---|---|---|
efficiency |
0.1.0 |
adaptive-skills |
Jump to
- Overview
- When to use
- When not to use
- Core moves
- Expected output
- Verification
- Handoff signals
- Pairs well with
- Anti-patterns
View the canonical contract on GitHub.
Overview
Use this skill when a round needs a short, useful pause before continuing, so the next move is chosen deliberately instead of by momentum.
When to Use
- the session is getting long or heavy
- the task changed shape mid-round
- the team needs to decide whether to continue, stop, or hand off
- a quick review is cheaper than carrying ambiguity forward
When NOT to Use
- the task is still in a very small, obvious execution pass
- the work needs full macro gate or escalation rather than a local checkpoint
- the round has already closed cleanly with no meaningful uncertainty left
Core Moves
- State what changed in this round.
- State what is now known or proved.
- Name what still remains unresolved.
- Decide whether the next step belongs in the same round, a new round, or a handoff.
- Record the stop-or-continue rationale.
Optional Modules
- Proof recap — list the checks or artifacts that justify the current state.
- Boundary test — ask whether the next step crosses into a different ownership or operating context.
- Continuation cap — add an explicit stop point when the team is tempted to keep going by inertia.
Activation Triggers
- Use proof recap when the current state depends on validation that could be forgotten quickly.
- Use boundary test when the next step may need another skill, owner, or review posture.
- Use continuation cap when the round keeps growing even though the key objective is already met.
Expected Output
- what changed
- what is now proved
- what remains open
- continue / stop / handoff decision
- rationale for that decision
Verification
- The round outcome is clearer after the checkpoint than before it.
- The continue-or-stop decision is explicit.
- Proven work is separated from assumed work.
- The checkpoint reduces ambiguity instead of adding ceremony.
Handoff Signals
- The next step needs a different owner, skill, or operating context.
- The round should stop and resume later with a fresh summary.
- Macro review, escalation, or gate posture is now required.
Pairs Well With
workflowtask-chunkinghandoff-summary
Anti-patterns
- Treating a checkpoint as a long retrospective.
- Continuing only because the team already has momentum.
- Using a checkpoint to avoid making a real stop-or-continue decision.