Checkpoint
Overview
Create a safe, repeatable checkpoint in any git repo. This workflow is swarm-safe: it acquires a lock, validates, stages selected files, commits with strict message rules, and optionally pushes.
Principles
- Automate what is unambiguous; ask when it is not.
- Never switch branches or rewrite history unless explicitly instructed.
- Prefer explicit file selection; avoid "stage everything" by default.
- Abort if the working tree changes mid-run.
Workflow (Swarm-Safe)
1) Acquire Lock
Use a repo-local lock so multiple agents do not collide.
- Lock path:
.git/.checkpoint.lock/
- Create the lock with an atomic
mkdir. If it exists, stop and report.
- Write
owner.txt inside the lock with: user, host, pid, time, branch, worktree.
- Only break the lock if the user explicitly says "force".
If the lock is present, show owner.txt and stop. Do not proceed unless told to force.
2) Snapshot
- Record
git status -sb and a diff summary.
- If on
master, warn and ask for confirmation before continuing.
- If the working tree changes after this point, abort and report.
3) Validate
Run the repo's standard checks, but do not guess commands.
- Discover validation instructions from repo docs/config (README, CONTRIBUTING, build scripts, CI notes).
- If the repo does not specify validation steps, ask the user to choose or skip.
- If validation fails, fix and re-run before proceeding.
4) Stage
- Show the diff and ask which files to include.
- Stage only the files the user confirms (explicit paths only).
- Re-check
git status and the diff. If anything changed unexpectedly, abort.
5) Commit
Ask for a commit message and enforce these rules (verbatim):
- Subject <=42 chars (room for
(#NNNN) suffix -> 50 char limit)
- Imperative mood ("Add feature" not "Added feature")
- Capitalize subject, no period at end
- Blank line between subject and body
- Body: explain what and why, wrap at 72 chars
- Use backticks around
filenames, paths, and code_symbols
Use the heredoc pattern:
git commit -m "$(cat <<'EOF'
<Subject line - imperative, <=42 chars>
<Body - what and why, wrapped at 72 chars>
Use `backticks` around files, paths, symbols.
EOF
)"
If commit fails:
- No staged changes -> return to Stage
- Hook failure -> fix, re-stage, create a NEW commit (do not amend)
- Other error -> report and stop
6) Push (Optional)
- Ask whether to push unless the user explicitly requested it.
- If pushing: fetch first. If remote advanced or diverged, stop and ask.
- Push only the current branch.
7) Confirm and Release
- Summarize what happened (files staged, commit SHA, push status).
- Remove the lock directory only after completion.
Notes
- No PR or Graphite steps in this skill.
- The lock directory is created by this workflow to prevent collisions; it is safe to remove only when no checkpoint is running.
1---2name: checkpoint-33description: Swarm-safe git checkpoint workflow to validate, stage, commit, and optionally push work in any repo. Use when user says "checkpoint", "save", "commit", "stage and commit", or wants a safe, repeatable snapshot.4---5
6# Checkpoint
7
8## Overview
9
10Create a safe, repeatable checkpoint in any git repo. This workflow is swarm-safe: it acquires a lock, validates, stages selected files, commits with strict message rules, and optionally pushes.
11
12## Principles
13
14- Automate what is unambiguous; ask when it is not.
15- Never switch branches or rewrite history unless explicitly instructed.
16- Prefer explicit file selection; avoid "stage everything" by default.
17- Abort if the working tree changes mid-run.
18
19## Workflow (Swarm-Safe)
20
21### 1) Acquire Lock
22
23Use a repo-local lock so multiple agents do not collide.
24
25- Lock path: `.git/.checkpoint.lock/`
26- Create the lock with an atomic `mkdir`. If it exists, stop and report.
27- Write `owner.txt` inside the lock with: user, host, pid, time, branch, worktree.
28- Only break the lock if the user explicitly says "force".
29
30If the lock is present, show `owner.txt` and stop. Do not proceed unless told to force.
31
32### 2) Snapshot
33
34- Record `git status -sb` and a diff summary.
35- If on `master`, warn and ask for confirmation before continuing.
36- If the working tree changes after this point, abort and report.
37
38### 3) Validate
39
40Run the repo's standard checks, but do not guess commands.
41
42- Discover validation instructions from repo docs/config (README, CONTRIBUTING, build scripts, CI notes).
43- If the repo does not specify validation steps, ask the user to choose or skip.
44- If validation fails, fix and re-run before proceeding.
45
46### 4) Stage
47
48- Show the diff and ask which files to include.
49- Stage only the files the user confirms (explicit paths only).
50- Re-check `git status` and the diff. If anything changed unexpectedly, abort.
51
52### 5) Commit
53
54Ask for a commit message and enforce these rules (verbatim):
55
561. Subject <=42 chars (room for ` (#NNNN)` suffix -> 50 char limit)
572. Imperative mood ("Add feature" not "Added feature")
583. Capitalize subject, no period at end
594. Blank line between subject and body
605. Body: explain what and why, wrap at 72 chars
616. Use backticks around `filenames`, `paths`, and `code_symbols`
62
63Use the heredoc pattern:
64
65```bash
66git commit -m "$(cat <<'EOF'
67<Subject line - imperative, <=42 chars>
68
69<Body - what and why, wrapped at 72 chars>
70Use `backticks` around files, paths, symbols.
71EOF
72)"
73```
74
75If commit fails:
76
77- No staged changes -> return to Stage
78- Hook failure -> fix, re-stage, create a NEW commit (do not amend)
79- Other error -> report and stop
80
81### 6) Push (Optional)
82
83- Ask whether to push unless the user explicitly requested it.
84- If pushing: fetch first. If remote advanced or diverged, stop and ask.
85- Push only the current branch.
86
87### 7) Confirm and Release
88
89- Summarize what happened (files staged, commit SHA, push status).
90- Remove the lock directory only after completion.
91
92## Notes
93
94- No PR or Graphite steps in this skill.
95- The lock directory is created by this workflow to prevent collisions; it is safe to remove only when no checkpoint is running.
majiayu000