메뉴
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 페이지를 검토하고 설치를 진행할 수 있습니다.
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 | 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: