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.
Profile →npx skills add code-yeongyu/oh-my-openagent --skill start-work --agent claude-code
Same command for any agent — swap --agent for codex, cursor, copilot.
Weekly change comes from our own snapshots, not the repository page — it measures attention, not adoption.
What it does
Executes a Prometheus work plan until all top-level checkboxes are complete, coordinating with a harness continuation hook that re-injects the next turn while the Boulder state indicates unchecked plan work.
How it works
- The skill acts as an orchestrator, not an implementer, delegating all implementation tasks to subagents and managing plan selection, Boulder state (.omo/boulder.json), ledger entries for phases and tasks, decomposition of checkboxes into sub-tasks, and evidence records.
- After a plan is selected, it performs Phase 2 to ensure Boulder state is prepared (writing .omo/boulder.json with active_work_id, worktree_path, etc.). For PR/branch work, it requires a worktree path and may create one via the prescribed flow; all edits and evidence capture occur inside the worktree.
- In Phase 3, it reads the chosen plan, identifies the first unchecked top-level checkbox, classifies the checkbox Tier (default LIGHT unless a HEAVY fact is observed), decomposes into atomic sub-tasks, and delegates all sub-tasks through the delegation router, dispatching independent sub-tasks in one parallel burst while ensuring dependencies serialize by name.
- It follows a set of delivery lanes rules and uses a per-checkbox verification and marking process.
- The usage line indicates how to invoke:
$start-work [plan-name] [--worktree <absolute-path>] [--make-pr] [--ship]with corresponding meanings for plan-name, worktree, --make-pr, and --ship.
When to use it
Use after planning when the user says start work, execute plan, continue plan, resume plan, or asks to run a .omo/plans plan.
What it can touch
- It writes and updates
.omo/boulder.jsonto reflect active work and plan state. - It reads the plan from the chosen
.omo/plans/path and updates the ledger and evidence records via the harness delegation flow. - It uses the provided tools listed in the skill declaration: claude-code, codex, cursor.
Caveats
- The file describes a strict orchestration role that never implements code itself; all implementation tasks are delegated to spawned subagents.
- The behavior assumes presence of a plan in
.omo/plans/and a Boulder state file at.omo/boulder.jsonand may trigger worktree creation for PR/branch scenarios. - The description emphasizes maximum parallelism for independent tasks and serializes only named dependencies.
## ABSOLUTE RULE: YOU ARE AN ORCHESTRATOR — NEVER THE IMPLEMENTER **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. ## Codex Harness Tool Compatibility 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|medium|high>"` when the spawn schem
- ABSOLUTE RULE: YOU ARE AN ORCHESTRATOR — NEVER THE IMPLEMENTER
- Codex Harness Tool Compatibility
- Codex tier mapping for the delegation router
- Codex Subagent Reliability
- Usage
- Goal and todo discipline (MANDATORY)
- Phase 1: Select the plan
- No-plan bootstrap
- Phase 2: Create or update Boulder state
- Parallel delivery lanes (teams and worktrees)
- Phase 3: Execute the next checkbox
- Delegation router — recommended task executor category
- Phase 4: Verify and record evidence
- Sisyphus-style completion contract
What does the start-work skill do?
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.
How do I install it?
Run `npx skills add code-yeongyu/oh-my-openagent --skill start-work --agent claude-code` — it drops the skill into your project so the agent can pick it up. Swap the --agent value for codex, cursor or copilot if you use one of those.
Where does this skill come from?
From code-yeongyu/oh-my-openagent, a repository with 67,209 stars. We read it straight from the repository tree rather than a submitted listing, so what you see here is what is actually published.
Is a popular skill a good skill?
Not necessarily. Stars measure attention, not adoption — a repository can trend for a week and be abandoned. That is why we show the weekly change from our own snapshots next to the total, instead of a single flattering number.