| name | waypoint |
| description | Read, write, or check status of session checkpoints for multi-session project continuity. Use when the user says 'checkpoint', 'waypoint', 'save progress', 'session handoff', or wants to review, create, or check the freshness of a .context/checkpoint.md file. |
| arguments | [{"name":"action","description":"The operation to perform: read, write, or status"}] |
| argument-hint | [read|write|status] |
| user-invocable | true |
| allowed-tools | ["Read","Write","Edit","Bash"] |
Waypoint
Session checkpoint management for multi-session project continuity.
Actions
read
Read and summarize the current checkpoint.
- Read
.context/checkpoint.md
- Present a brief summary: what was done, what's next, and how to resume
- If the file does not exist, report that no checkpoint exists and suggest running
/waypoint-init to bootstrap the project
write
Write or update the session checkpoint. Follow the format spec below exactly.
- Gather context: current branch (
git branch --show-current), today's date, work completed this session, decisions made, and next steps
- If
docs/plans/ exists, check for plan files matching the current branch name or title. Note any completed implementation units for the Done section
- Write
.context/checkpoint.md using the format spec below
- Verify the file is under 40 lines
Checkpoint Format Spec
---
date: <today's date, YYYY-MM-DD>
branch: <current git branch>
---
## Done
- <completed work with file paths or commit SHAs>
## Next
- <the specific next step, with enough context to start cold>
## Decisions
- <any decisions or context that would be lost without this file>
## Resume
<exact instruction to resume: branch to check out, files to read, command to run>
Rules:
- Keep it under 40 lines total
- The checkpoint must have enough context for a fresh session to pick up without re-reading the entire codebase
- Be specific in Resume: name the branch, the files, the command
- Done items should reference concrete artifacts (file paths, commit SHAs, plan unit numbers)
Plan-Tracking Rules
When working on a project with plans in docs/plans/:
- After completing a plan implementation unit, update its checkbox:
- [ ] becomes - [x] with the completion date appended (e.g., - [x] **Unit 1: ...** (2026-04-13))
- After completing a brainstorm or plan artifact, update the corresponding row in any meta-plan tracking table that references it
- In commit messages that complete a plan unit, include
[unit:N] where N is the unit number (e.g., feat(carrying-cost): add heuristic engine [unit:1])
status
Report checkpoint freshness and current session state.
- Check if
.context/checkpoint.md exists
- If it exists: report last modified time, age, current git branch, and whether there are uncommitted changes or new commits since the checkpoint
- If it does not exist: report that no checkpoint exists