菜单
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: