| name | ghe-checkpoint |
| description | POST a progress checkpoint to the CURRENTLY ACTIVE thread. Saves work state without changing phases. Requires an already-claimed in-progress thread. USE THIS SKILL WHEN: - User says "post a checkpoint" or "save my progress" - User says "update the issue" or "record current state" - User says "checkpoint" or "save checkpoint" - User completed a milestone and wants to record it - User encountered a blocker and wants to document it - User is about to take a break and wants to save state - Meaningful state change occurred during work PRECONDITION: User must already have an active (claimed, in-progress) thread. DO NOT USE THIS SKILL WHEN: - User wants to SEE status (use ghe-status) - User wants to START work on new issue (use ghe-claim) - User wants to FINISH current phase and MOVE to next (use ghe-transition) - User wants reports (use ghe-report) - No active thread exists (must claim first) EXAMPLES: <example> Context: User working on DEV wants to save progress user: "Post a checkpoint" assistant: "I'll use ghe-checkpoint to post your current progress to the active thread" </example> <example> Context: User completed a milestone user: "Save my progress, I finished the authentication module" assistant: "I'll use ghe-checkpoint to record this milestone" </example> <example> Context: User taking a break user: "I need to stop for now, save my work" assistant: "I'll use ghe-checkpoint to save your current state before you go" </example> |
IRON LAW: User Specifications Are Sacred
THIS LAW IS ABSOLUTE AND ADMITS NO EXCEPTIONS.
- Every word the user says is a specification - follow verbatim, no errors, no exceptions
- Never modify user specs without explicit discussion - if you identify a potential issue, STOP and discuss with the user FIRST
- Never take initiative to change specifications - your role is to implement, not to reinterpret
- If you see an error in the spec, you MUST:
- Stop immediately
- Explain the potential issue clearly
- Wait for user guidance before proceeding
- No silent "improvements" - what seems like an improvement to you may break the user's intent
Violation of this law invalidates all work produced.
Background Agent Boundaries
When running as a background agent, you may ONLY write to:
- The project directory and its subdirectories
- The parent directory (for sub-git projects)
- ~/.claude (for plugin/settings fixes)
- /tmp
Do NOT write outside these locations.
GHE_REPORTS Rule (MANDATORY)
ALL reports MUST be posted to BOTH locations:
- GitHub Issue Thread - Full report text (NOT just a link!)
- GHE_REPORTS/ - Same full report text (FLAT structure, no subfolders!)
Report naming: <TIMESTAMP>_<title or description>_(<AGENT>).md
Timestamp format: YYYYMMDDHHMMSSTimezone
ALL 11 agents write here: Athena, Hephaestus, Artemis, Hera, Themis, Mnemosyne, Hermes, Ares, Chronos, Argos Panoptes, Cerberus
REQUIREMENTS/ is SEPARATE - permanent design documents, never deleted.
Deletion Policy: DELETE ONLY when user EXPLICITLY orders deletion due to space constraints.
Settings Awareness
Respects .claude/ghe.local.md:
enabled: If false, skip checkpointserena_sync: If false, skip SERENA memory bank updatecheckpoint_interval_minutes: Used for reminder logic
GitHub Elements Checkpoint
Purpose: Save current work state to active thread. Does NOT change phases.
Precondition
- Must have an active (claimed, in-progress) thread
- If no active thread, use
ghe-claimfirst
When to Use
- Save progress during work
- Document milestones
- Record blockers
- Before ending session
- At meaningful state changes
How to Execute
Step 1: Find active thread
Check for issues assigned to @me with "in-progress" label.
If no active thread found:
- Inform user
- Suggest using
ghe-claimto start work
Step 2: Gather current state
Collect:
- Work log (what was done since last checkpoint)
- Completed tasks
- In-progress tasks
- Pending tasks
- Files changed
- Commits made
- Current branch
- Blockers (if any)
- Next action
Step 3: Post checkpoint
Spawn appropriate thread manager based on thread type:
dev→ dev-thread-managertest→ test-thread-managerreview→ review-thread-manager
The thread manager will post formatted checkpoint to issue.
Step 4: Sync memory
Spawn memory-sync agent to update activeContext.md.
Checkpoint Format
## [<TYPE> Session N] DATE TIME UTC - @me
### Work Log
- [HH:MM] Action 1
- [HH:MM] Action 2
### State Snapshot
#### Thread Type
<dev | test | review>
#### Completed
- [x] Task 1
#### In Progress
- [ ] Task 2 (N% complete)
#### Pending
- [ ] Task 3
#### Files Changed
| File | Changes |
#### Commits
| Hash | Message |
#### Branch
`feature/branch-name`
#### Blockers
[None | List]
#### Next Action
[Specific next step]
### Scope Reminder
[Phase-specific abilities and limits]
Output
Confirmation that:
- Checkpoint posted to issue
- Memory bank updated
Key Differentiator
This skill SAVES progress without changing phases. To COMPLETE current phase and MOVE to next, use ghe-transition instead.