Menu
Use when doing code work that must be integration-friendly: branches, commits, tests, PR-ready receipts, owned paths, and parent-friendly handoff.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
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.
Use when inspecting the live fleet, differentiating active vs historical lineage, tracing ancestry, checking subtree state, or doing post-mortem investigation.
| name | code-delivery |
| description | Use when doing code work that must be integration-friendly: branches, commits, tests, PR-ready receipts, owned paths, and parent-friendly handoff. |
Use this skill when your task changes code, tests, build files, interfaces, or deployment behavior.
Produce work that a parent can integrate and report upward without rereading the entire codebase.
Before proposing architecture or decomposition:
ls or treeAGENTS.md, HANDOFF.md, and equivalent handoff/spec docs if presentDo not start with a long self-briefing. Start with concrete repo orientation.
After orientation, decide where the work belongs:
resource_vm is warrantedFor non-trivial repo builds, make the ownership decision early:
Root should not remain the implicit main worker while those decisions are still vague.
For repo implementation requests, assume the output should run outside Reef root unless the user explicitly asked to extend Reef itself. Root's default role is to orient, delegate, supervise, and integrate. Do not make root the default home for the product you are building.
Before building a UI or service, choose the deployment target explicitly:
Default to the separate VM path unless the work is clearly part of Reef's own operator UI or control plane.
If the task includes standing up and exposing a product/application service, use skills/app-deployment/SKILL.md.
Do not create chaotic local state and call it progress.
Work inside your assigned ownership boundary:
If you discover that the assigned boundary is wrong:
Run the cheapest truthful verification that matches the task:
When you cannot run the right test:
When you report upward, include:
If your parent cannot continue without reopening the same files you just worked in, your receipts are too weak.
Parents own integration.
Children should:
Parents should:
Do not pretend that delegation alone solves integration.
If your assigned code slice still contains multiple independent subsystems:
skills/decompose/SKILL.mdIf it is one coherent implementation slice:
Recursion is for structural separation, not for avoiding responsibility.
If the repo contains local guidance, treat it as first-class planning input before architecture or decomposition decisions.
Typical high-value files:
AGENTS.mdHANDOFF.mddocs/working/handoffs/docs/working/subspecs/Do not infer the product from directory names alone if the repo already explains itself.