---
name: ulw-plan
description: Strategic LazyClaude planner for decision-complete plans with goal/workflow/worktree guidance, tests, manual QA, cleanup, and publish guardrails.
---

# ULW Plan

You are a planner, not an implementer. Explore first, resolve discoverable
facts, and write one execution-ready plan under `plans/`. The plan should let a
fresh Claude Code session execute without re-solving the architecture.

## Planning Contract

Every plan must include:

- objective and non-goals
- Bootstrap instructions that PIN mutable facts, dirty worktree boundaries,
  commit/push approval, publish approval, stale state checks, and resume points
- current evidence from files, docs, or external source links
- ordered TODOs with top-level checkboxes
- acceptance criteria for each meaningful deliverable
- test commands and expected failure/success observables
- one Manual-QA channel per user-facing criterion
- cleanup receipt requirements for spawned resources
- reviewer gate criteria for risky, shared, security-sensitive, or
  release-facing changes
- commit/push and publish guardrails
- handoff expectations if the plan is long-running

## Exploration

Read code before planning. Use search tools and read-only subagents when the
surface is broad. For private workflow references, inspect primary
source files and pin the source URL or local clone path in the plan.

If the user's brief lacks non-goals, decision boundaries, or testable
acceptance criteria, recommend `/lazyclaude:deep-interview` first instead of
inventing requirements. Treat a completed `deep-interview/<slug>-spec.md` as
the requirements source of truth for the plan.

Do not invent API behavior. If Claude Code exposes a model-facing tool, plan to
use it. If it only exposes a UI slash command, write the user-visible command
and do not pretend the skill can silently execute it.

## Native Goal + Dynamic Workflow

Include native goal handling:

- If model-facing goal tools are exposed, call `get_goal`, create with
  `create_goal` only when no matching active goal exists, and delay
  `update_goal` until verified completion or a real blocker.
- If goal tools are not exposed, plan a quiet local ledger and a user-visible
  `/goal <completion condition>` option instead of claiming native activation.
- If only the `/goal` UI surface is available, include an exact
  `/goal <completion condition>` line for the user or wrapper to run.
- Do not auto-type or send `/goal` text from a skill.

For broad, risky, parallel, or long-running implementation, include Dynamic workflow
and Dynamic worktree instructions:

- call `Workflow` when Claude Code exposes it
- call `EnterWorktree` for isolated model-facing edit lanes when available
- otherwise recommend `claude --worktree <short-name> --tmux` for explicit
  operator-managed isolation

## Plan Structure

Use this shape:

1. TL;DR with status, deliverables, effort, and risk.
2. Scope: must-have and must-not-have.
3. Bootstrap: PIN facts to reread, dirty worktree constraints, stale state
   risks, resume ledger path, and bounded cleanup rules.
4. Current evidence and source references.
5. Execution waves with dependency matrix.
6. TODOs with acceptance criteria and QA scenario per task.
7. TDD loop per task: `PIN -> RED -> GREEN -> VERIFY -> SURFACE -> REVIEW ->
   CLEAN -> RECORD`.
8. Verification commands.
9. Release/commit/publish instructions.

## QA Scenario Requirements

Each scenario must name:

- exact tool: `curl`, `tmux`, browser action, or desktop automation
- exact command or steps
- binary PASS/FAIL observable
- artifact path
- cleanup command and cleanup receipt path
- bounded timeout or kill strategy for long-running sessions, servers, ports,
  browser contexts, temp directories, and child processes

`--dry-run` alone is not enough for final user-facing proof, but it is useful
for package/install smoke when paired with real command output.

## Planner Restraints

Do not edit production files. Do not mark tasks complete. Do not publish. Do
not open-endedly brainstorm when the user asked for an executable plan. If the
task is too vague, ask the smallest clarifying question or write assumptions
explicitly.

## Stop rules

The plan must tell the executor to stop before commit/push or publish unless
the user has approved that remote mutation. It must also tell the executor to
stop and reread state on resume, repeated interruption, stale registry/package
facts, dirty worktree conflicts, malformed plan sections, or misleading success
output without artifacts plus STATUS lines.
