القائمة
Use when signaling done/blocked/failed, reporting artifacts upward, or deciding whether to create a checkpoint before risky or meaningful state transitions.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use when doing code work that must be integration-friendly: branches, commits, tests, PR-ready receipts, owned paths, and parent-friendly handoff.
Use when implementing and exposing a product/application service or UI that should run outside Reef root. Choose child/resource VM placement, stand up the app, and report how to reach it.
Use when handling parent commands such as steer, abort, pause, or resume, or when deciding how urgently to react to inbox messages from above.
Use when agents need to coordinate through reef store, peer signals, barriers, rendezvous, or child/peer communication without breaking authority boundaries.
Create a new service module for reef. Use when adding a new capability to the server — a new store, API routes, LLM tools, behaviors, or dashboard widget.
Use when a task has multiple independent subsystems, needs recursive delegation, or requires a parent to split implementation and then integrate the results.
| 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. |
Use this skill when you are about to finish, fail, block, or checkpoint meaningful work.
When signaling done, include artifact pointers that let your parent continue without guessing:
When signaling blocked or failed, include:
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.
Before fully disengaging, decide post-task state in this order:
stay_idle / stop_when_done)If you remain alive and idle, make that explicit in your final signal so your parent knows you are available for reuse. If you stop when done, make sure your final signal contains enough artifact pointers that replacement or follow-up work can resume cleanly.
If ownership changed during execution, make that explicit too:
Do not leave stale scheduled checks, store keys, or parent expectations pointing at a child that no longer owns the slice.
Use reef_checkpoint when:
General guidance:
If a parent may need to recover or replace you later, make sure your signal and your checkpoint together are enough to reconstruct the situation.