---
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.
6. PIN the current objective, stale state to reread, dirty worktree boundaries,
   commit/push approval, publish approval, resume checkpoint, and required
   cleanup receipt paths before editing.

## 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. PIN the exact file scope, non-goals, and stale facts that must be refreshed.
3. Write or update the test first; capture RED when behavior changes.
4. Implement the smallest change and capture GREEN with the targeted test.
5. Run broader verification requested by the plan.
6. Run the plan's Manual-QA scenario and capture the SURFACE artifact.
7. Run the reviewer gate when the checkbox is broad, risky, shared,
   security-sensitive, or release-facing.
8. Clean resources and capture cleanup receipt. Cleanup must be bounded with a
   timeout or kill path for tmux sessions, servers, ports, browser contexts,
   temp directories, and child processes.
9. Mark the top-level checkbox complete only after evidence exists.
10. 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.

Use `PIN -> RED -> GREEN -> VERIFY -> SURFACE -> REVIEW -> CLEAN -> RECORD` as
the execution shorthand. If any step is missing, leave the checkbox open.

## Evidence Standards

Every completed checkbox needs:

- automated test command and result
- manual QA artifact path
- cleanup receipt
- reviewer result or a recorded reason the reviewer gate was not required
- 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.

On resume after cancel, compaction, terminal restart, or repeated interruption,
reread the plan, ledger, `.omo/boulder.json`, and `git status --short` before
acting. Treat prior green output as stale unless the artifact path still exists
and includes the command plus STATUS line. Never revert dirty worktree changes
you did not make.

## 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.

## Stop rules

Stop before commit/push or publish unless the user approved it for this run.
Stop when the plan is malformed, missing acceptance criteria, missing Manual-QA
channels, missing cleanup receipts, or contradicts current repository state.
Record the blocker and the next executable command instead of guessing.
