---
name: start-work
description: Execute a checked plan file with LazyClaude Boulder state, top-level checkbox discipline, goal/workflow/worktree bootstrap, evidence ledgers, and cleanup receipts.
---

# Start Work

Use this skill when the user asks to execute a plan file, especially
`$start-work plans/<slug>.md`. The plan file and ledger are the source of truth,
not memory.

## Bootstrap

Before the first edit:

1. Read the requested plan file.
2. Read `.omo/start-work/ledger.jsonl` when it exists.
3. Inspect `.omo/boulder.json` when it exists.
4. Pick the first unchecked top-level checkbox in `## TODOs` or final
   verification sections. Ignore nested acceptance criteria as task selectors.
5. Decompose that checkbox into atomic tasks with tests and QA artifacts.

## Native Goal + Dynamic Workflow

Before the first checkbox, use Claude Code's native goal surface when available:

- call `get_goal` if exposed
- call `create_goal` with the plan objective only when no matching active goal
  exists
- call `update_goal` only after all top-level checkboxes and final gates are
  complete, or when the plan is genuinely blocked
- if the user invokes `/goal`, respect it as the native session goal
- do not auto-type or send `/goal` text from a skill

If model-facing goal tools are absent, continue with Boulder/ledger discipline.
For long plans, ask once for `/goal <plan completion condition>` if that would
help the user keep the session bounded.
If goal tools are not exposed, do not print repeated fallback status; just keep
the plan ledger accurate and continue with verified evidence.

For broad, risky, or parallel checkbox waves, use Dynamic workflow orchestration
and call `Workflow` when exposed. Use Dynamic worktree isolation with
`EnterWorktree` for isolated model-facing edit lanes when available. When
only the CLI path is available, use or recommend
`claude --worktree <short-name> --tmux`.

## Per-Checkbox Loop

For the selected checkbox:

1. Re-read the checkbox, acceptance criteria, and prior evidence.
2. Write or update the test first; capture RED when behavior changes.
3. Implement the smallest change.
4. Run targeted tests.
5. Run the plan's manual QA scenario.
6. Clean resources and capture cleanup receipt.
7. Mark the top-level checkbox complete only after evidence exists.
8. Append a `task-completed` line to `.omo/start-work/ledger.jsonl`.

Do not mark every checkbox at the end in a batch. Progress is durable and
incremental.

## Evidence Standards

Every completed checkbox needs:

- automated test command and result
- manual QA artifact path
- cleanup receipt
- changed files or commit hash when applicable
- any skipped adversarial classes with reason

`--dry-run`, "looks right", or a worker's self-report is insufficient.

## Failure Handling

If a subtask fails, retry the same task with the exact error, diagnosis, and
fix instruction. After repeated identical failures, stop and surface the
blocker with artifacts. Do not start fresh and lose the failure context.

## Finalization

When all top-level checkboxes are complete, run the plan's final verification
wave, update the plan file, update the ledger, commit/push if requested, and
leave a handoff if the session stops at a checkpoint.
