| 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. |
Code Delivery
Use this skill when your task changes code, tests, build files, interfaces, or deployment behavior.
Goal
Produce work that a parent can integrate and report upward without rereading the entire codebase.
Repo Orientation Playbook
Before proposing architecture or decomposition:
- run
ls or tree
- inspect top-level files
- identify the language, package manager, and build system
- identify test entrypoints
- read the README and relevant package/build manifests
- read repo-local
AGENTS.md, HANDOFF.md, and equivalent handoff/spec docs if present
- only then decide whether to implement directly or decompose
Do not start with a long self-briefing. Start with concrete repo orientation.
After orientation, decide where the work belongs:
- small, coherent slice -> do it directly
- multi-subsystem build -> decompose
- support infrastructure or a side environment -> consider whether a child or
resource_vm is warranted
For non-trivial repo builds, make the ownership decision early:
- who owns the main implementation slice
- who owns persistent operations
- who owns support infrastructure
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.
