メニュー
Use when inspecting the live fleet, differentiating active vs historical lineage, tracing ancestry, checking subtree state, or doing post-mortem investigation.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
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.
SOC 職業分類に基づく
| name | fleet-inspection |
| description | Use when inspecting the live fleet, differentiating active vs historical lineage, tracing ancestry, checking subtree state, or doing post-mortem investigation. |
Use this skill when you need to understand what is live now versus what happened earlier.
Operational default:
Examples:
vm_tree_view() -> active fleetvm_tree_view({ includeHistory: true }) -> active + historical lineagereef_fleet_status() -> live operational childrenActive view answers:
History view answers:
Running resource_vm instances may still appear in the active view even if the parent subtree is historical.
This is a rendering/operational behavior. It does not mutate stored lineage.
Use history-inclusive views if you need the original parent-child structure.
For stopped descendants:
Do not confuse: