workspace-checkpoint
Skill6 starsChanged 3 months agoMITView on GitHub
Reactivate the smallest set of decision-governing constraints immediately before a consequential action, without introspection, full-context summarization, or a new durable artifact.
In this repository23 other files it gives its agents.
- AGENTS.mdAGENTS.md
- analyze-miniSkill
- bug-captureSkill
- build-oneSkill
- ceremony-budgetSkill
- checklist-miniSkill
- constitution-liteSkill
- context-checkSkill
- diagnose-loopSkill
- eco-modeSkill
- falsify-specSkill
- grill-with-docs-liteSkill
- handoffSkill
- lean-modeSkill
- mini-specSkill
- operator-profileSkill
- scope-freezeSkill
- ship-miniSkill
- teach-backSkill
- test-miniSkill
- thin-planSkill
- tool-noise-guardSkill
- verify-contractSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
13 rules. About 0 are common, 11 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈11
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 14
Checkpoint, do not summarize: Read only the highest-authority sources needed for the next action and carry forward the smallest useful …
- Distinctive: line 18
Use only at a real decision boundary where a buried or competing constraint could change the next action, for example:
- Distinctive: line 20
before weakening or rewriting a test, fixture, or compatibility seam
- Distinctive: line 21
before widening an API, schema, dependency, permission, or write scope
- Distinctive: line 22
before an irreversible or shared-state mutation
- Distinctive: line 23
before declaring success when evidence is mixed or incomplete
- Distinctive: line 24
before the first consequential edit after a resume or handoff
- Distinctive: line 25
after repeated failures when the next attempt risks drifting from the original contract
- Distinctive: line 42
Read the smallest authoritative source set needed to govern that action.
- Very specific: line 45
If sources materially conflict, do not silently reconcile them.
- Distinctive: line 47
Treat the checkpoint as expired when the action completes, the evidence changes, or the governing source changes.
- Very specific: line 68
Do not create WORKSPACE.md, a checkpoint ledger, or another permanent state file merely to prove the skill ran.
- Distinctive: line 76
If explicitly invoked and no real decision boundary exists, output only:
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Workspace Checkpoint
Purpose
Re-center the next consequential action on the few current constraints and evidence that can change it.
Reactivate, do not introspect. This skill externalizes decision-relevant state; it does not ask the model to reveal private reasoning or claim access to internal representations.
Checkpoint, do not summarize. Read only the highest-authority sources needed for the next action and carry forward the smallest useful active set.
When to use
Use only at a real decision boundary where a buried or competing constraint could change the next action, for example:
- before weakening or rewriting a test, fixture, or compatibility seam
- before widening an API, schema, dependency, permission, or write scope
- before an irreversible or shared-state mutation
- before declaring success when evidence is mixed or incomplete
- before the first consequential edit after a resume or handoff
- after repeated failures when the next attempt risks drifting from the original contract
Skip routine edits, ordinary tool calls, and already-bounded steps whose governing constraint is obvious and current.
A long conversation by itself is not a trigger. Use context-check for context drift, tool-noise-guard for repetitive tool envelopes, verify-contract for proof, and handoff for continuation state.
Inputs
- Exact next action and target
- Current user request and project instructions
- Current task artifacts such as
SPEC.md,VERIFY.md, orHANDOFF.mdwhen relevant - Directly governing code, tests, schemas, or other authoritative references
- Hard constraints, non-goals, compatibility seams, evidence, and stop conditions that can change the next action
Workflow
- Name the exact next action. Do not checkpoint an entire project or phase.
- Read the smallest authoritative source set needed to govern that action.
- Select only constraints and evidence that can change what happens next. Prefer 1-3 governing constraints.
- Emit at most the six-line checkpoint block below.
- If sources materially conflict, do not silently reconcile them. Stop or route to the smallest skill that can resolve the conflict, such as
mini-spec,scope-freeze, or a human decision. - Take the named action immediately once the checkpoint is coherent.
- Treat the checkpoint as expired when the action completes, the evidence changes, or the governing source changes. Recompute only at the next real decision boundary.
Checkpoint block
WORKSPACE CHECKPOINT
Action: ...
Governing constraints: ...
Current evidence: ...
Open risk: ...
Stop / escalate if: ...Authority rule
A checkpoint is a working projection of live sources, not a new source of truth.
Current user instructions and current project state outrank the checkpoint. Current task artifacts outrank stale examples or prior checkpoints. If the checkpoint disagrees with a higher-authority source, discard or refresh it.
No durable artifact by default
Do not create WORKSPACE.md, a checkpoint ledger, or another permanent state file merely to prove the skill ran.
Persist a constraint only when it must survive the current decision boundary. Put durable state in the artifact that already owns it: SPEC.md, VERIFY.md, HANDOFF.md, project instructions, or the relevant code/test contract.
Outputs
Normally one ephemeral WORKSPACE CHECKPOINT block followed by the named action.
If explicitly invoked and no real decision boundary exists, output only:
WORKSPACE CHECKPOINT: not needed — next action is already bounded.Stop conditions
- The exact next action is named.
- The smallest governing constraint set is active and source-backed.
- Material source conflicts are surfaced instead of silently resolved.
- The action starts immediately after the checkpoint.
- The checkpoint is not treated as durable truth after its action or evidence changes.
Anti-patterns
- Asking the model to reveal hidden thoughts, chain-of-thought, or internal representations.
- Summarizing the whole conversation before every meaningful step.
- Running a checkpoint before every edit, tool call, test, or command.
- Inventing a constraint because it sounds prudent rather than reading an authoritative source.
- Letting a stale checkpoint outrank current code, tests, task artifacts, or user instructions.
- Creating
WORKSPACE.mdor a checkpoint ledger for routine work. - Using the checkpoint instead of
context-check,verify-contract,ship-mini, orhandoff. - Claiming this skill implements, observes, or proves a model's internal global workspace.
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
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.

