/start-work

name: start-work
description: "Execute a Prometheus work plan in Codex 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."

Claude Code Harness Tool Compatibility

This skill may include examples copied from the OpenCode or Codex harness. In Claude Code, do not call OpenCode/Codex-only tools such as `task(...)`, `call_omo_agent(...)`, `spawn_agent(...)`, `background_output(...)`, `wait_agent(...)`, `team_*(...)`, `send_message(...)`, `followup_task(...)`, or `close_agent(...)` literally. Translate those examples to Claude Code native tools:

| OpenCode / Codex example | Claude Code tool to use | | --- | --- | | `task(subagent_type="explore", ...)` / `call_omo_agent(...)` / `spawn_agent(agent_type="explorer", ...)` | the `Task` tool (spawn a subagent of the matching type) | | `task(subagent_type="plan"/"oracle", ...)` / `spawn_agent(agent_type="plan"/"reviewer", ...)` | the `Task` tool with the planner/reviewer subagent, or the `Skill` tool | | `task(category="...", ...)` | the `Task` tool (general-purpose subagent) or run the work inline | | `background_output(...)` / `wait_agent(...)` | await the subagent's return value / the system completion notification | | `team_*(...)` / `send_message`/`followup_task`/`close_agent` | run multiple `Task` subagents and synthesize their results |

When translating `load_skills=[...]`, invoke the requested skills with the `Skill` tool or pass their names in the spawned subagent's prompt. If a code block below conflicts with this section, this section wins.

(superseded) Codex Harness Tool Compatibility

This skill ports the OpenCode `/start-work` flow onto Codex. Any OpenCode-only tool name in an inherited example must be translated to its Codex equivalent:

| OpenCode example | Codex tool to use | | --- | --- | | `task(subagent_type="explore", ...)` | `spawn_agent(agent_type="explorer", task_name="...", message="...")` | | `task(subagent_type="librarian", ...)` | `spawn_agent(agent_type="librarian", task_name="...", message="...")` | | `task(subagent_type="plan", ...)` | `spawn_agent(agent_type="plan", task_name="...", message="...")` | | `task(subagent_type="oracle", ...)` for final verification | `spawn_agent(agent_type="codex-ultrawork-reviewer", task_name="...", message="...")` | | `task(category="...", ...)` for implementation or QA | `spawn_agent(agent_type="worker", task_name="...", message="...")` | | `background_output(task_id="...")` | `wait_agent(...)` | | `dispatchInternalPrompt(...)` | the `Stop` hook emits `{"decision":"block","reason":"<prompt>"}` automatically; see Continuation | | `team_*(...)` | `spawn_agent` + `send_message` + `followup_task` + `wait_agent` + `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.

start-work

Execute a Prometheus work plan until every top-level checkbox is complete. This skill pairs with the Codex `Stop` / `SubagentStop` continuation hook in `components/start-work-continuation`, which re-injects the next turn while `.omo/boulder.json` says the current `codex:<session_id>` still has unchecked plan work.

Usage

$start-work [plan-name] [--worktree <absolute-path>]

• `plan-name` is optional. It may be a full or partial file stem under `.omo/plans/`.
• `--worktree` is optional. Use it only when the user explicitly asks to work in a separate git worktree.

Phase 1: Select the plan

1. Read `.omo/boulder.json` if it exists. 2. List Prometheus plan files under `.omo/plans/`. 3. If `plan-name` was provided, select the matching plan. 4. If exactly one active or paused Boulder work exists for this session, resume it. 5. If no active work exists and exactly one plan exists, select it. 6. If multiple plans remain possible, ask one focused selection question.

Phase 2: Create or update Boulder state

Write `.omo/boulder.json` before implementation starts. Session ids must be prefixed with `codex:` so the continuation hook can identify its own session.

{
  "schema_version": 2,
  "active_work_id": "<work-id>",
  "works": {
    "<work-id>": {
      "work_id": "<work-id>",
      "active_plan": ".omo/plans/<plan-name>.md",
      "plan_name": "<plan-name>",
      "session_ids": ["codex:<session_id>"],
      "status": "active",
      "worktree_path": null
    }
  }
}

If `--worktree` is set, verify the path with `git worktree list --porcelain` or create it with `git worktree add <path> <branch-or-HEAD>`, then store the absolute path as `worktree_path`. All edits, commands, tests, and evidence capture must run inside that worktree.

Phase 3: Execute the next checkbox

1. Read the full selected plan. 2. Find the first unchecked column-0 checkbox in `## TODOs` or `## Final Verification Wave`. 3. Ignore nested checkboxes under acceptance criteria, evidence, and definition-of-done sections. 4. Decompose that checkbox into atomic sub-tasks. 5. Dispatch independent sub-tasks in parallel with `spawn_agent`; serialize only when one sub-task has a named dependency on another.

Each sub-task message must include:

1. Goal and exact files or directories in scope. 2. Required red test or failing reproduction before production changes. 3. Implementation constraints from the plan and project rules. 4. Automated verification commands to run. 5. One Manual-QA channel: HTTP call, tmux session, browser use, or computer use. 6. Required artifact path and cleanup receipt.

Phase 4: Verify and record evidence

For each checkbox, complete all four gates before marking it done:

1. Plan reread: confirm the checkbox and acceptance criteria. 2. Automated verification: run tests, typecheck, lint, build, or the plan-specific equivalent. 3. Manual-QA channel: capture a real artifact,