| name | reporting-checkpointing |
| description | Use when signaling done/blocked/failed, reporting artifacts upward, or deciding whether to create a checkpoint before risky or meaningful state transitions. |
Reporting And Checkpointing
Use this skill when you are about to finish, fail, block, or checkpoint meaningful work.
Reporting upward
When signaling done, include artifact pointers that let your parent continue without guessing:
- PR URL or branch
- commit SHA
- store keys
- file paths
- VM/service identifiers when infrastructure is involved
- tests run and their result
- unresolved risks or deferred verification
- whether you remain alive/idle or are stopping after this task
When signaling blocked or failed, include:
- what you tried
- what failed
- what partial work exists
- where the parent should look next
Reporting rule
Do not optimize for a clean-looking signal.
Optimize for handoff quality.
For recursive code work, "done" means your parent can integrate your slice without re-reading the entire repo just to rediscover what changed.
Before you send your final done, do one bounded inbox catch-up. If new parent/child/peer attention arrived after you finished the main task, either handle a small in-scope follow-up immediately or mention it explicitly in your final signal.
For swarm workers, only claim a final inbox catch-up if your runtime/task path actually left you a bounded final pass before exit. Do not imply a universal self-directed catch-up when the swarm runtime completed atomically.
Disposition-aware conclusion
Before fully disengaging, decide post-task state in this order:
- explicit parent disposition (
stay_idle / )
