Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →code-yeongyu/start-work
Execute a Prometheus work plan with Boulder state, evidence ledger updates, worktree discipline, parallel subagents, and Stop-hook continuation. Use after planning when the user says start work, execute plan, continue plan, resume plan, or asks to run a .omo/plans plan.
5 of 25 test cases passed with the skill.
Tokens, turns and time describe resource use, not a dollar price.
Lift withheld: 6 comparable cases; this report requires 8.
One of 3 test cases the skill fixed. Same model, same prompt, with and without the skill.
Prepare a task delegation call for a worker on a system exposing multi_agent_v2 subagent tools with required task_name.
| Checked | Without skill | With skill |
|---|---|---|
| Uses spawn_agent with task_name and fork_turns parameters. | Missed | Passed |
The instructions your model reads when the skill loads.
YOU DO NOT WRITE CODE. YOU DO NOT EDIT PRODUCT FILES. YOU DO NOT RUN QA YOURSELF. EVERY unit of implementation, test, QA, and review work MUST be delegated to a spawned subagent. NO EXCEPTIONS. Your hands touch only plan selection, .omo/ state (Boulder, ledger, plan checkboxes), decomposition, dispatch, verdicts, and evidence records. About to edit a product file or run an implementation command yourself? STOP. SPAWN A WORKER INSTEAD. Orchestrate at MAXIMUM PARALLELISM: every independent unit runs concurrently; only named dependencies serialize.
Translate any OpenCode-only tool name in an inherited example to its Codex equivalent:
| OpenCode example | Codex tool to use |
|---|---|
final-review task(...) | multi_agent_v1.spawn_agent({"message":"TASK: act as a rigorous reviewer. ...","agent_type":"lazycodex-gate-reviewer","fork_context":false}) |
worker task(...) | multi_agent_v1.spawn_agent({"message":"TASK: act as <role>. ...","fork_context":false}) — for implementation workers add `agent_type: "lazycodex-worker-<low |
background_output(task_id="...") | multi_agent_v1.wait_agent(...) for mailbox signals |
team_*(...) | multi_agent_v1.spawn_agent + multi_agent_v1.send_input + multi_agent_v1.wait_agent + multi_agent_v1.close_agent |
When translating load_skills=[...], name the skills inside the spawned agent's message. If a code block below conflicts with this section, this section wins.
Codex exposes ONE of two subagent tool surfaces per session; check your own tool list and route accordingly. If multi_agent_v1.* tools exist, use the table above as written. If instead a flat spawn_agent with a required task_name exists (multi_agent_v2), rewrite every multi_agent_v1.* example: multi_agent_v1.spawn_agent({...,"fork_context":false}) becomes spawn_agent({"task_name":"<lowercase_digits_underscores>","message":...,"agent_type":...,"fork_turns":"none"}) ("all" only when full parent history is truly required); send_input becomes send_message; do not call close_agent/resume_agent (finished agents end on their own; followup_task re-tasks one, interrupt_agent stops one); wait_agent takes only timeout_ms and returns on any child mailbox activity. On the v2 surface agent_type may be absent from the spawn schema — when absent, omit it and describe the role inside message. If a code block below conflicts with this section, this section wins.
When tier worker agents are installed, map the delegation router's parenthesized difficulty to agent_type: (low) -> lazycodex-worker-low; (medium) -> lazycodex-worker-medium; (high) -> lazycodex-worker-high. Explorer/librarian research lanes keep their own roles. On spawn surfaces without agent_type, state the tier inside message. Difficulty (model power) is orthogonal to the LIGHT/HEAVY rigor tier in step 4 — judge each on its own facts.
Every multi_agent_v1.spawn_agent message is a self-contained executable assignment: TASK: <imperative assignment>, then DELIVERABLE, SCOPE, and VERIFY, with role instructions inside message. Use fork_context: false unless full history is truly required; paste only the context the child needs.
Plan and reviewer agents may run for a long time: spawn them in the background and keep doing independent root work. Between multi_agent_v1.wait_agent calls, back off — double the timeout up to ~5 minutes — instead of spinning short cycles. A timeout only means no new mailbox update arrived; treat a running child as alive. Require WORKING: <task> - <current phase> before long passes and BLOCKED: <reason> only when progress stops. Keep the parent visibly alive with active subagent count, names, and latest WORKING: phase. Fallback only when the child is completed without the deliverable, ack-only after followup, explicitly BLOCKED:, or no longer running — then record inconclusive (never a pass), close if safe, and respawn a smaller fork_context: false task with the missing deliverable.
Execute a Prometheus work plan until every top-level checkbox is complete. This skill pairs with the harness's start-work continuation hook, which re-injects the next turn while .omo/boulder.json says this codex:<session_id> still has unchecked plan work.
$start-work [plan-name] [--worktree <absolute-path>] [--make-pr] [--ship]
plan-name (optional): a full or partial file stem under .omo/plans/.--worktree (required for PR/branch work; otherwise optional): the task-owned git worktree path.test cases passed with the skill
More skills from the same source and nearby in the registry, with their headline benchmark lift.