---
name: ulw-loop
description: Evidence-bound LazyClaude execution loop with goal/workflow/worktree bootstrap, RED->GREEN tests, manual QA artifacts, cleanup receipts, and continuation ledgers.
---

# ULW Loop

Use this skill when the user asks for `ulw`, `ultrawork`, `$ulw-loop`, or an
evidence-bound implementation loop. It is the Claude Code port of LazyClaude
Ultrawork/Ultragoal discipline.

When the request is still underspecified, pause execution and route to
`/lazyclaude:deep-interview` or a completed `deep-interview/<slug>-spec.md`
before planning or editing. ULW execution should not invent non-goals, decision
boundaries, or acceptance criteria.

## Role

Deliver the user's objective end-to-end. Convert the objective into explicit
success criteria before editing. Keep decisions, evidence, cleanup receipts,
and remaining work in a durable notepad, plan, or ledger when the task spans
multiple steps.

## Bootstrap

Before implementation:

1. Read the relevant files and existing plans/handoffs.
2. PIN the objective, non-goals, commit/push boundary, publish boundary, and
   any dirty worktree files that must not be reverted.
3. Define 3+ success criteria covering happy path, edge/regression, and
   adversarial risk.
4. Pair each criterion with a failing automated test or reproduction.
5. Pair each criterion with one real Manual-QA channel.
6. Register cleanup for every tmux session, process, port, browser context, or
   temp directory as soon as it is created.
7. Reread stale state before action: plans, handoffs, package metadata,
   registry facts, test output, and resumed ledgers can drift between turns.

## Native Goal + Dynamic Workflow

Use Claude Code's native goal surface when available:

- If model-facing tools exist, call `get_goal`, call `create_goal` only when no
  matching active goal exists, and call `update_goal` only after every success
  criterion has evidence or the work is genuinely blocked.
- If the user chooses `/goal`, treat it as the native Claude Code session goal.
  LazyClaude must not auto-type or send `/goal` text.
- If model-facing goal tools are not exposed, continue quietly with the local
  evidence ledger. Mention `/goal <completion condition>` only when it helps a
  long-running task; do not spam fallback status.

Dynamic workflow orchestration is mandatory for broad, risky, parallel, or
long-running work: call `Workflow` when exposed instead of merely mentioning it.
Dynamic worktree isolation is mandatory for risky edit lanes: call
`EnterWorktree` when exposed. If only the CLI surface is available, use or
recommend `claude --worktree <short-name> --tmux`.

## Manual-QA Channels

Pick one channel per criterion and run it:

- HTTP: `curl -i <url>` with status, headers, and body captured.
- tmux: `tmux new-session -d -s <name> '<command>'`, capture pane output, then
  kill the session and prove cleanup.
- Browser: drive the real page, capture action log and screenshot.
- Computer use: automate the actual desktop app and capture action log.

Tests are the floor. Manual QA is the ceiling.

## Execution Loop

For each criterion:

1. PIN: restate the criterion, non-goal, stale state to reread, and rollback
   limits before editing.
2. RED: write the failing test first and capture the failing output.
3. GREEN: implement the smallest correct change.
4. VERIFY: run targeted tests and relevant full suite.
5. SURFACE: run the manual QA scenario through the chosen channel.
6. REVIEW: run the reviewer gate or request a review when the change is broad,
   risky, security-sensitive, or release-facing.
7. CLEAN: tear down every spawned resource and record the cleanup receipt.
   Cleanup must be bounded: include timeout/kill commands for long-running
   tmux sessions, servers, child processes, and browser contexts.
8. RECORD: update the notepad/ledger with PASS, FAIL, or BLOCKED.

Repeat the same criterion after a fix; do not jump to a new criterion while the
current one has missing evidence.

Use the shorthand `PIN -> RED -> GREEN -> VERIFY -> SURFACE -> REVIEW -> CLEAN
-> RECORD` when writing plans or ledgers. The SURFACE step must include a
Manual-QA artifact, not only automated tests.

## Adversarial Classes

Probe relevant classes:

- malformed input
- prompt injection
- cancel/resume
- stale state
- dirty worktree
- hung or long commands
- flaky tests
- misleading success output
- repeated interruptions

If a class does not apply, record the one-line reason.

## Stop rules

Stop only when all criteria have green automated evidence, real channel
artifacts, cleanup receipts, and the required commit/push or publish instruction
has been handled. If blocked, record the exact blocker and the next executable
command.

Stop immediately before remote mutations unless the user has requested the
commit/push or publish action in this session. On resume, reread the ledger and
latest git status before continuing. Never revert dirty worktree changes you did
not make; either work around them or ask when they block the task.

## Porting Note

LazyClaude original Ultrawork text is intentionally demanding. LazyClaude keeps
that pressure but replaces source-specific mechanics with Claude Code surfaces. If a
future Claude release exposes native goal tools directly, keep the same
evidence gate and simply swap the local ledger bootstrap for the native tool
calls.
