oh-my-opencode 5.0.0-beta.19 → 5.0.0-beta.20

package/packages/omo-codex/plugin/skills/ulw-plan/references/intent-unclear.md

@@ -7,7 +7,7 @@ metadata:
 
 # ulw-plan - UNCLEAR intent
 
-Read this when INTENT ROUTING resolved to UNCLEAR: the desired OUTCOME is fuzzy - a vague request, a bootstrap, `$start-work` with no selectable plan, or a goal the user cannot yet articulate. Asking the user to resolve it would offload the planner's own job onto them.
+Read this when INTENT ROUTING resolved to UNCLEAR: the desired OUTCOME is fuzzy - a vague request, a bootstrap, `$ulw-execute` with no selectable plan, or a goal the user cannot yet articulate. Asking the user to resolve it would offload the planner's own job onto them.
 
 <stance>
 PRIME DIRECTIVE: do NOT interrogate the user. Resolve ambiguity by RESEARCH, not questions. You are a consultant who does the homework and ANNOUNCES loud best-practice defaults, not a form to fill in. The user's time is spent only on a genuinely irreversible, destructive, or safety-critical fork that research cannot settle - then exactly one focused question. Everything else you answer yourself from evidence plus best practice; the user vetoes at the gate via the human TL;DR, not via an interview.
@@ -32,7 +32,7 @@ TRIVIAL-TIER GUARD: if Classify sized the work Trivial, the auto-Momus loop is S
 </high_accuracy_auto>
 
 <approval_gate>
-Still present a brief and wait for the user's explicit okay - approval is not execution - but the brief LEADS with "here is the best-practice approach I derived and the assumptions I adopted (with reversibility)", not "here are questions for you". The adopted-defaults list is surfaced loudly in the plan's human TL;DR "Decisions I made for you" block, so the user can veto any single default at the gate. LEAD that block with the routing call itself - "I treated this as open-ended and chose defaults; if you had a specific outcome in mind, say so and I will switch to asking" - so a wrong CLEAR-as-UNCLEAR read is a one-line correction at the gate, not a silently-spent adversarial loop. Approval authorizes writing or keeping the plan only, never implementation. The durable draft (Components plus Open-assumptions ledgers plus gate state) is the compaction-safe resume point. ($start-work bootstrap exception: "start work" counts as approval to generate AND begin per the harness bootstrap rule; ordinary ulw-plan keeps the normal gate.)
+Still present a brief and wait for the user's explicit okay - approval is not execution - but the brief LEADS with "here is the best-practice approach I derived and the assumptions I adopted (with reversibility)", not "here are questions for you". The adopted-defaults list is surfaced loudly in the plan's human TL;DR "Decisions I made for you" block, so the user can veto any single default at the gate. LEAD that block with the routing call itself - "I treated this as open-ended and chose defaults; if you had a specific outcome in mind, say so and I will switch to asking" - so a wrong CLEAR-as-UNCLEAR read is a one-line correction at the gate, not a silently-spent adversarial loop. Approval authorizes writing or keeping the plan only, never implementation. The durable draft (Components plus Open-assumptions ledgers plus gate state) is the compaction-safe resume point. ($ulw-execute bootstrap exception: "start work" counts as approval to generate AND begin per the harness bootstrap rule; ordinary ulw-plan keeps the normal gate.)
 </approval_gate>
 
 <worked_example>

package/packages/omo-codex/plugin/test/aggregate-hooks.test.mjs

@@ -32,7 +32,7 @@ test("#given isolated components #when hooks are inspected #then commands stay i
 		"components/lsp/dist/cli.js",
 		"components/codegraph/dist/cli.js",
 		"components/rules/dist/cli.js",
-		"components/start-work-continuation/dist/cli.js",
+		"components/ulw-execute-continuation/dist/cli.js",
 		"components/telemetry/dist/cli.js",
 		"components/teammode/dist/cli.js",
 		"components/ulw-loop/dist/cli.js",
@@ -48,7 +48,7 @@ test("#given isolated components #when hooks are inspected #then commands stay i
 	assert.equal(await exists("scripts/migrate-codex-config.mjs"), true);
 });
 
-test("#given aggregate Stop hooks #when inspected #then start-work continuation and ulw-loop resume are separate groups", async () => {
+test("#given aggregate Stop hooks #when inspected #then ulw-execute continuation and ulw-loop resume are separate groups", async () => {
 	// given
 	const manifests = await readAggregateHookManifests();
 
@@ -60,11 +60,11 @@ test("#given aggregate Stop hooks #when inspected #then start-work continuation
 
 	// then
 	assert.equal(stopCommands.length, 2);
-	assert.ok(stopCommands.some((command) => command.includes("start-work-continuation/dist/cli.js")));
+	assert.ok(stopCommands.some((command) => command.includes("ulw-execute-continuation/dist/cli.js")));
 	assert.ok(stopCommands.some((command) => command.includes("ulw-loop/dist/cli.js\" hook stop")));
 });
 
-test("#given aggregate SubagentStop hooks #when inspected #then start-work and LazyCodex executor verifier are separate groups", async () => {
+test("#given aggregate SubagentStop hooks #when inspected #then ulw-execute and LazyCodex executor verifier are separate groups", async () => {
 	// given
 	const manifests = await readAggregateHookManifests();
 

package/packages/omo-codex/plugin/test/aggregate-manifest.test.mjs

@@ -60,10 +60,10 @@ test("#given component directories #when scanned #then only intentional resource
 		"lazycodex-executor-verify",
 		"lsp",
 		"rules",
-		"start-work-continuation",
 		"teammode",
 		"telemetry",
 		"ultrawork",
+		"ulw-execute-continuation",
 		"ulw-loop",
 	]);
 	for (const name of componentNames) {

package/packages/omo-codex/plugin/test/component-bin-names.test.mjs

@@ -10,9 +10,9 @@ const EXPECTED_COMPONENT_BINS = new Map([
 	["comment-checker", ["omo-comment-checker"]],
 	["lsp", ["omo-lsp"]],
 	["rules", ["omo-rules"]],
-	["start-work-continuation", ["omo-start-work-continuation"]],
 	["telemetry", ["omo-telemetry"]],
 	["ultrawork", ["omo-ultrawork"]],
+	["ulw-execute-continuation", ["omo-ulw-execute-continuation"]],
 	["ulw-loop", ["omo-ulw-loop", "ulw", "ulw-loop"]],
 ]);
 
@@ -20,9 +20,9 @@ const EXPECTED_USAGE_PREFIXES = new Map([
 	["comment-checker", "Usage: omo-comment-checker "],
 	["lsp", "Usage: omo-lsp "],
 	["rules", "Usage: omo-rules "],
-	["start-work-continuation", "Usage: omo-start-work-continuation "],
 	["telemetry", "Usage: omo-telemetry "],
 	["ultrawork", "Usage: omo-ultrawork "],
+	["ulw-execute-continuation", "Usage: omo-ulw-execute-continuation "],
 ]);
 
 async function readJson(relativePath) {

package/packages/omo-codex/plugin/test/component-bundled-cli.test.mjs

@@ -25,7 +25,7 @@ const HOOK_EVENTS_BY_COMPONENT = {
 	"lazycodex-executor-verify": "subagent-stop",
 	lsp: "post-compact",
 	rules: "session-start",
-	"start-work-continuation": "stop",
+	"ulw-execute-continuation": "stop",
 	telemetry: "session-start",
 	teammode: "post-tool-use",
 	ultrawork: "user-prompt-submit",

package/packages/omo-codex/plugin/test/component-hook-contract-cases.mjs

@@ -202,8 +202,8 @@ export function componentHookContractCases(tempRoot) {
 			},
 		},
 		{
-			name: "start-work-continuation stop no state",
-			component: "start-work-continuation",
+			name: "ulw-execute-continuation stop no state",
+			component: "ulw-execute-continuation",
 			event: "stop",
 			payload: {
 				hook_event_name: "Stop",

package/packages/omo-codex/plugin/test/hook-status-message.test.mjs

@@ -30,8 +30,8 @@ const AGGREGATE_EXPECTED_LABELS = new Map([
 	["hooks/hooks.json:PostCompact:0:0", "Resetting Git Bash MCP Reminder"],
 	["hooks/hooks.json:PostCompact:1:0", "Resetting Project Rule Cache"],
 	["hooks/hooks.json:PostCompact:2:0", "Resetting LSP Diagnostics Cache"],
-	["hooks/hooks.json:Stop:0:0", "Checking Start-Work Continuation"],
-	["hooks/hooks.json:SubagentStop:0:0", "Checking Start-Work Continuation"],
+	["hooks/hooks.json:Stop:0:0", "Checking Ulw-Execute Continuation"],
+	["hooks/hooks.json:SubagentStop:0:0", "Checking Ulw-Execute Continuation"],
 	["hooks/hooks.json:SubagentStop:1:0", "Verifying LazyCodex Executor Evidence"],
 ]);
 
@@ -47,8 +47,8 @@ const COMPONENT_EXPECTED_LABELS = new Map([
 	["components/ultrawork/hooks/hooks.json:UserPromptSubmit:0:0", "Checking Ultrawork Trigger"],
 	["components/ulw-loop/hooks/hooks.json:UserPromptSubmit:0:0", "Checking Ulw-Loop Steering"],
 	["components/ulw-loop/hooks/hooks.json:PreToolUse:0:0", "Enforcing Unlimited Ulw-Loop Budget"],
-	["components/start-work-continuation/hooks/hooks.json:Stop:0:0", "Checking Start-Work Continuation"],
-	["components/start-work-continuation/hooks/hooks.json:SubagentStop:0:0", "Checking Start-Work Continuation"],
+	["components/ulw-execute-continuation/hooks/hooks.json:Stop:0:0", "Checking Ulw-Execute Continuation"],
+	["components/ulw-execute-continuation/hooks/hooks.json:SubagentStop:0:0", "Checking Ulw-Execute Continuation"],
 	[
 		"components/lazycodex-executor-verify/hooks/hooks.json:SubagentStop:0:0",
 		"Verifying LazyCodex Executor Evidence",

package/packages/omo-codex/plugin/test/sync-skills-test-support.mjs

@@ -23,10 +23,10 @@ export const expectedSkills = [
 	"remove-ai-slops",
 	"review-work",
 	"rules",
-	"start-work",
 	"teammode",
 	"ultimate-browsing",
 	"ultrawork",
+	"ulw-execute",
 	"ulw-loop",
 	"ulw-plan",
 	"ulw-research",
@@ -69,33 +69,33 @@ export function removeCodexCompatibilityGuidance(content) {
 	return `${content.slice(0, start)}${content.slice(end + endMarker.length)}`;
 }
 
-const startWorkOriginalCompletion = `When all top-level checkboxes in \`## TODOs\` and \`## Final Verification Wave\` are complete:
+const ulwExecuteOriginalCompletion = `When all top-level checkboxes in \`## TODOs\` and \`## Final Verification Wave\` are complete:
 
 1. Run the plan's final verification commands.
 2. For PR/branch work, finish the lifecycle from the task-owned worktree: sync \`.omo/\` state back to the main repo, create or update the PR, wait for review/verification gates, merge by default unless explicitly opted out, and remove the worktree only after successful merge or explicit handoff.
 3. Remove or mark the Boulder work as completed.
 4. Print an \`ORCHESTRATION COMPLETE\` block with the plan path, verification commands, artifacts, and cleanup receipts.`;
 
-const startWorkCodexCompletion = `When all top-level checkboxes in \`## TODOs\` and \`## Final Verification Wave\` are complete:
+const ulwExecuteCodexCompletion = `When all top-level checkboxes in \`## TODOs\` and \`## Final Verification Wave\` are complete:
 
 1. Run the plan's final verification commands.
 2. Complete the **Global Review and Debugging Gate** before any completion claim, PR creation, PR handoff, branch handoff, or merge:
    - Invoke the \`review-work\` skill with the final diff, changed files, user goal, constraints, run command, and verification evidence. All five review lanes must return PASS. A timeout, missing deliverable, ack-only child, \`BLOCKED:\`, or inconclusive lane is a gate failure, not approval.
-   - Each passing review lane binds to the exact full commit SHA it reviewed. Immediately append a durable record to \`.omo/start-work/ledger.jsonl\` with the lane name, full SHA, PASS verdict, and report artifact/source. Before same-SHA reuse after any continuation or compaction, re-read the ledger record and require the exact lane/SHA pair; memory, chat history, or an unstamped report is not coverage. New commits require fresh applicable lane coverage.
-   - Run a debugging-oriented runtime audit even when the review passes: name at least three plausible failure hypotheses for the changed surface, run the distinguishing checks against the actual artifact, and append a separate durable record with the audit name, exact full SHA, verdict, and evidence artifact/source to \`.omo/start-work/ledger.jsonl\`. Reuse it only after re-reading an exact audit/SHA match.
+   - Each passing review lane binds to the exact full commit SHA it reviewed. Immediately append a durable record to \`.omo/ulw-execute/ledger.jsonl\` with the lane name, full SHA, PASS verdict, and report artifact/source. Before same-SHA reuse after any continuation or compaction, re-read the ledger record and require the exact lane/SHA pair; memory, chat history, or an unstamped report is not coverage. New commits require fresh applicable lane coverage.
+   - Run a debugging-oriented runtime audit even when the review passes: name at least three plausible failure hypotheses for the changed surface, run the distinguishing checks against the actual artifact, and append a separate durable record with the audit name, exact full SHA, verdict, and evidence artifact/source to \`.omo/ulw-execute/ledger.jsonl\`. Reuse it only after re-reading an exact audit/SHA match.
    - If any review lane or debugging hypothesis fails, invoke the \`debugging\` skill, confirm root cause with runtime evidence, add the minimal failing test or reproduction, fix it, rerun the affected verification, then rerun the Global Review and Debugging Gate.
-   - Evidence hygiene is mandatory: redact or mask secrets and sensitive user data before writing \`.omo/start-work/ledger.jsonl\`, a PR body, or a handoff. Never include raw tokens, credentials, auth headers, cookies, API keys, env dumps, private logs, or PII; use concise summaries, lengths, hashes, or short non-sensitive prefixes instead.
+   - Evidence hygiene is mandatory: redact or mask secrets and sensitive user data before writing \`.omo/ulw-execute/ledger.jsonl\`, a PR body, or a handoff. Never include raw tokens, credentials, auth headers, cookies, API keys, env dumps, private logs, or PII; use concise summaries, lengths, hashes, or short non-sensitive prefixes instead.
    - If the work includes creating, updating, or handing off a PR, refresh \`git status\` and the PR/branch state from the task-owned worktree after the gate, and include only redacted review/debugging evidence in the PR body or handoff.
 3. Finish the PR/branch lifecycle from its task-owned worktree: sync \`.omo/\` state back to the main repo, create or update the PR when requested, wait for CI/review/Cubic gates, merge by default unless explicitly opted out, and remove the worktree only after successful merge or explicit handoff.
 4. Remove or mark the Boulder work as completed.
 5. Print an \`ORCHESTRATION COMPLETE\` block with the plan path, verification commands, Global Review and Debugging Gate verdict, artifacts, and cleanup receipts.`;
 
-const startWorkOriginalHardRule = "- No completion claim while an applicable ultraqa adversarial class was never probed. Each applicable class needs a captured observable result; each skipped class needs a one-line not-applicable reason in the ledger.\n- No PR/branch implementation, review, or merge in the main worktree; use the task-owned git worktree.\n- No unprefixed session ids in Boulder state. Sessions are always recorded as `codex:<session_id>`.";
+const ulwExecuteOriginalHardRule = "- No completion claim while an applicable ultraqa adversarial class was never probed. Each applicable class needs a captured observable result; each skipped class needs a one-line not-applicable reason in the ledger.\n- No PR/branch implementation, review, or merge in the main worktree; use the task-owned git worktree.\n- No unprefixed session ids in Boulder state. Sessions are always recorded as `codex:<session_id>`.";
 
-const startWorkCodexHardRule = "- No completion claim while an applicable ultraqa adversarial class was never probed. Each applicable class needs a captured observable result; each skipped class needs a one-line not-applicable reason in the ledger.\n- No `ORCHESTRATION COMPLETE`, final response, PR creation, PR handoff, or merge before the Global Review and Debugging Gate passes with recorded evidence.\n- No PR/branch implementation or review in the main worktree; create or use a task-owned git worktree first.\n- No unprefixed session ids in Boulder state. Sessions are always recorded as `codex:<session_id>`.";
+const ulwExecuteCodexHardRule = "- No completion claim while an applicable ultraqa adversarial class was never probed. Each applicable class needs a captured observable result; each skipped class needs a one-line not-applicable reason in the ledger.\n- No `ORCHESTRATION COMPLETE`, final response, PR creation, PR handoff, or merge before the Global Review and Debugging Gate passes with recorded evidence.\n- No PR/branch implementation or review in the main worktree; create or use a task-owned git worktree first.\n- No unprefixed session ids in Boulder state. Sessions are always recorded as `codex:<session_id>`.";
 
 const reviewWorkCodexGate = `
-When \`review-work\` is used as a final implementation, PR, or \`$start-work\`
+When \`review-work\` is used as a final implementation, PR, or \`$ulw-execute\`
 gate, it is blocking. A timeout, missing deliverable, ack-only response,
 explicit \`BLOCKED:\`, or inconclusive lane is not a pass. Treat that lane as
 failed, investigate the underlying uncertainty with the \`debugging\` skill when
@@ -134,10 +134,10 @@ export function removeCodexSkillOverlays(skillName, content) {
 	if (skillName === "ulw-research") {
 		return content.replace(ulwResearchCodexDeliveryGate, ulwResearchOriginalDeliveryGates);
 	}
-	if (skillName === "start-work") {
+	if (skillName === "ulw-execute") {
 		return content
-			.replace(startWorkCodexCompletion, startWorkOriginalCompletion)
-			.replace(startWorkCodexHardRule, startWorkOriginalHardRule);
+			.replace(ulwExecuteCodexCompletion, ulwExecuteOriginalCompletion)
+			.replace(ulwExecuteCodexHardRule, ulwExecuteOriginalHardRule);
 	}
 	if (skillName === "review-work") {
 		return content.replace(reviewWorkCodexGatePattern, "");

package/packages/omo-codex/scripts/install-dist/install-local.mjs

@@ -1,5 +1,5 @@
 #!/usr/bin/env node
-// omo-codex-install:1d8359e77ebe41655f091cd2e455f320cde2f9c681f0651797c47d8fdfa2dd76:fe42a5610803f06b84bc9fe0b1f98d651e9b8420a522c804cb85bec2668149b7
+// omo-codex-install:475155d5e39ca774e5cf86194fee97439fd9c4f3624a85e946a994d5493e4629:1c7c73a68c1147fffd78df8bfc0126f38e77464c42debb2efd312e3997209eff
 var __defProp = Object.defineProperty;
 var __returnValue = (v) => v;
 function __exportSetter(name, newValue) {
@@ -7962,7 +7962,7 @@ var package_default;
 var init_package = __esm(() => {
   package_default = {
     name: "@oh-my-opencode/omo-codex",
-    version: "5.0.0-beta.19",
+    version: "5.0.0-beta.20",
     type: "module",
     private: true,
     description: "Codex harness adapter for oh-my-openagent. Vendored Codex plugin namespace (omo) + TypeScript installer + telemetry.",
@@ -8682,9 +8682,9 @@ var LEGACY_CODEX_COMPONENT_BINS = [
   { name: "codex-comment-checker", component: "comment-checker" },
   { name: "codex-lsp", component: "lsp" },
   { name: "codex-rules", component: "rules" },
-  { name: "codex-start-work-continuation", component: "start-work-continuation" },
   { name: "codex-telemetry", component: "telemetry" },
-  { name: "codex-ultrawork", component: "ultrawork" }
+  { name: "codex-ultrawork", component: "ultrawork" },
+  { name: "codex-ulw-execute-continuation", component: "ulw-execute-continuation" }
 ];
 var LEGACY_CODEX_COMPONENT_BIN_NAMES = LEGACY_CODEX_COMPONENT_BINS.map((entry) => entry.name);
 async function removeLegacyCodexComponentBins(binDir, platform) {

package/packages/shared-skills/skills/frontend/SKILL.md

@@ -107,7 +107,7 @@ Domains: `product` `style` `typography` `color` `landing` `chart` `ux` `react` `
 
 ## Ruleset 4 — designpowers (`references/designpowers/`)
 
-`README.md` routes the pinned `Owl-Listener/designpowers` corpus into this workflow. It supplies design context — personas, accessibility and cognitive constraints, critique, debt, handoff, synthetic user testing, motion, role prompts — that must be distilled into `DESIGN.md` first, then used as the implementation contract. It replaces nothing: not this skill, not `/visual-qa`, `/ulw-plan`, `/start-work`, or `/review-work`.
+`README.md` routes the pinned `Owl-Listener/designpowers` corpus into this workflow. It supplies design context — personas, accessibility and cognitive constraints, critique, debt, handoff, synthetic user testing, motion, role prompts — that must be distilled into `DESIGN.md` first, then used as the implementation contract. It replaces nothing: not this skill, not `/visual-qa`, `/ulw-plan`, `/ulw-execute`, or `/review-work`.
 
 ## Quick routes — most common requests
 

package/packages/shared-skills/skills/frontend/references/designpowers/README.md

@@ -9,7 +9,7 @@ The purpose of this ruleset is to enrich the existing frontend workflow while pr
 - `references/design/README.md` still owns the `DESIGN.md` contract, taste routing, brand references, React dev tooling, and browser-based design QA expectations.
 - `references/perfection/README.md` still owns Lighthouse, performance, SEO, accessibility audit mechanics, and real-browser verification.
 - `/visual-qa` still owns objective rendered evidence for visual claims.
-- `/ulw-plan`, `/start-work`, and `/review-work` still own planning, execution, and final implementation review when those phases apply.
+- `/ulw-plan`, `/ulw-execute`, and `/review-work` still own planning, execution, and final implementation review when those phases apply.
 
 ## Load Order
 

package/packages/shared-skills/skills/frontend/references/designpowers/lane-a-direction.md

@@ -61,4 +61,4 @@ Lane A passes only when the plan has inspectable design context, not vague inten
 
 PASS when `ulw-plan` receives this lane context and produces a decision-complete plan whose tasks are design-aware, persona-aware, and evidence-bound.
 
-FAIL when the plan skips inclusive-personas, buries accessibility as a final polish item, treats taste as generic style, writes a parallel design plan, or leaves design decisions for start-work workers to invent.
+FAIL when the plan skips inclusive-personas, buries accessibility as a final polish item, treats taste as generic style, writes a parallel design plan, or leaves design decisions for ulw-execute workers to invent.

package/packages/shared-skills/skills/frontend/references/designpowers/lane-b-execution.md

@@ -1,25 +1,25 @@
 # Lane B: Design Execution Guidance
 
-Lane B feeds `start-work` workers and always loads `frontend` for UI implementation. It does not install a separate builder. Its job is to carry designpowers composition, interaction, motion, content, responsive, adaptive, token, and cognitive-accessibility guidance into worker prompts while keeps ownership of decomposition, implementation, QA, evidence, and ledger updates.
+Lane B feeds `ulw-execute` workers and always loads `frontend` for UI implementation. It does not install a separate builder. Its job is to carry designpowers composition, interaction, motion, content, responsive, adaptive, token, and cognitive-accessibility guidance into worker prompts while keeps ownership of decomposition, implementation, QA, evidence, and ledger updates.
 
 ## Phase Owner
 
 | Capability | Materialized designpowers source | owner | Mapping |
 |---|---|---|---|
-| Visual hierarchy, layout, color, typography, touch targets, and WCAG contrast | `ui-composition` | `start-work` worker plus `frontend` | Add visual constraints and acceptance checks to worker assignments. `frontend` remains the required UI implementation skill. |
-| States, feedback, loading, error, keyboard, touch, and recovery behavior | `interaction-design` | `start-work` worker plus `frontend` | Require every interactive component to define default, hover, focus, active, disabled, loading, success, and error states where applicable. |
-| Purposeful motion and reduced-motion alternatives | `motion-choreography` | `start-work` worker plus `frontend` | Require motion specs to explain what changed, what to look at next, or how elements relate; require safe alternatives. |
-| Content-driven breakpoints and zoom behavior | `responsive-patterns` | `start-work` worker plus `frontend` | Require responsive proof at narrow, mid, desktop, and 200 percent zoom scenarios when the surface is visual. |
-| User preference adaptation | `adaptive-interfaces` | `start-work` worker plus `frontend` | Require support for relevant preferences such as color scheme, contrast, reduced motion, text sizing, and density. |
-| Mental load, wayfinding, focus management, memory demands, and recovery paths | `cognitive-accessibility` | `start-work` worker plus `frontend` | Add COGA-style checks directly to worker acceptance criteria for flows, forms, navigation, and dense tools. |
-| Plain-language labels, headings, alt text, link text, errors, and instructions | `accessible-content` and `voice-and-tone` | `start-work` worker plus `frontend` | Require final copy, no placeholders, useful errors, readable labels, and consistent tone. |
+| Visual hierarchy, layout, color, typography, touch targets, and WCAG contrast | `ui-composition` | `ulw-execute` worker plus `frontend` | Add visual constraints and acceptance checks to worker assignments. `frontend` remains the required UI implementation skill. |
+| States, feedback, loading, error, keyboard, touch, and recovery behavior | `interaction-design` | `ulw-execute` worker plus `frontend` | Require every interactive component to define default, hover, focus, active, disabled, loading, success, and error states where applicable. |
+| Purposeful motion and reduced-motion alternatives | `motion-choreography` | `ulw-execute` worker plus `frontend` | Require motion specs to explain what changed, what to look at next, or how elements relate; require safe alternatives. |
+| Content-driven breakpoints and zoom behavior | `responsive-patterns` | `ulw-execute` worker plus `frontend` | Require responsive proof at narrow, mid, desktop, and 200 percent zoom scenarios when the surface is visual. |
+| User preference adaptation | `adaptive-interfaces` | `ulw-execute` worker plus `frontend` | Require support for relevant preferences such as color scheme, contrast, reduced motion, text sizing, and density. |
+| Mental load, wayfinding, focus management, memory demands, and recovery paths | `cognitive-accessibility` | `ulw-execute` worker plus `frontend` | Add COGA-style checks directly to worker acceptance criteria for flows, forms, navigation, and dense tools. |
+| Plain-language labels, headings, alt text, link text, errors, and instructions | `accessible-content` and `voice-and-tone` | `ulw-execute` worker plus `frontend` | Require final copy, no placeholders, useful errors, readable labels, and consistent tone. |
 | Tokens and design-system consistency | `token-architecture` and `design-system-alignment` | `frontend` | Require real design tokens and existing component patterns before new one-off styling. |
 
 Materialized agent references for this lane: `design-lead`, `motion-designer`, and `content-writer`. They are prompt-role references for spawned OpenAgent work, not alternate executors.
 
 ## Prompt Injection
 
-Add this block to each `start-work` implementation worker that touches UI:
+Add this block to each `ulw-execute` implementation worker that touches UI:
 
 ```text
 Load `frontend` for UI implementation. Also apply Lane B Design Execution Guidance.
@@ -43,7 +43,7 @@ Do not invent visual direction that conflicts with the plan. If the plan lacks a
 Lane B worker DoneClaims must include:
 
 - Exact changed files and the `frontend` references loaded.
-- The real-surface QA invocation required by `start-work` for the UI surface, with captured artifact path.
+- The real-surface QA invocation required by `ulw-execute` for the UI surface, with captured artifact path.
 - Screenshot, browser, HTTP, or xterm.js web-terminal artifacts appropriate to the visible surface.
 - Accessibility evidence from the existing OpenAgent frontend path, such as Lighthouse, react-doctor, keyboard checks, or other plan-required checks.
 - A short design trace: which persona, design principle, token, or state requirement each major UI decision satisfies.
@@ -52,7 +52,7 @@ Lane B worker DoneClaims must include:
 ## Guardrails
 
 - UI implementation always goes through `frontend`; Lane B only enriches the worker prompt.
-- `start-work` owns decomposition, worker dispatch, evidence ledger entries, adversarial checks, and completion state.
+- `ulw-execute` owns decomposition, worker dispatch, evidence ledger entries, adversarial checks, and completion state.
 - The materialized `design-builder` concept is not used as an available executor. OpenAgent workers build.
 - No placeholders, generic copy, unverified contrast claims, decorative-only motion, or one-off hardcoded design systems pass this lane.
 - Accessibility and cognitive-accessibility are implementation constraints, not review-only cleanup.

package/packages/shared-skills/skills/frontend/references/designpowers/lane-d-memory.md

@@ -7,7 +7,7 @@ Lane D records the design record around OpenAgent work. It owns `.omo/frontend-d
 | Capability | Source boundary | owner | Mapping |
 |---|---|---|---|
 | Track deferred design and accessibility findings | `design-debt-tracker` | `.omo/frontend-design/state.md` plus final `review-work` context | Maintain a register with ID, date, source, severity, issue, affected users, suggested fix, status, and notes. |
-| Package design rationale for implementers or reviewers | `design-handoff` | `start-work` and `review-work` context | Record component, interaction, accessibility, content, and rationale notes that workers or reviewers need. |
+| Package design rationale for implementers or reviewers | `design-handoff` | `ulw-execute` and `review-work` context | Record component, interaction, accessibility, content, and rationale notes that workers or reviewers need. |
 | Reflect on process after completion | `design-retrospective` | final handoff context | Record what worked, what did not, fix rounds, debt health, and lessons. |
 | Maintain observational design memory | Authored concept preserved from excluded raw `design-memory` | `.omo/frontend-design/state.md` and optional personal report context | Store observations descriptively. Do not feed them back as future project constraints. |
 | Produce a taste reflection when requested | `taste-report` | user-facing handoff only | Summarize personal-layer observations only when enough evidence exists or the user asks. |
@@ -65,7 +65,7 @@ Lane D passes only when the record is inspectable:
 - Accessibility debt is either resolved or explicitly acknowledged by the user before acceptance.
 - Handoff notes cite concrete artifacts, decisions, constraints, and evidence paths.
 - Retrospective notes cite the final verification artifacts, unresolved debt, and lessons from fix rounds or user overrides.
-- The evidence index points to real files produced by OpenAgent planning, `start-work`, `visual-qa`, or `review-work`.
+- The evidence index points to real files produced by OpenAgent planning, `ulw-execute`, `visual-qa`, or `review-work`.
 
 ## Guardrails
 
@@ -78,6 +78,6 @@ Lane D passes only when the record is inspectable:
 
 ## Pass / Fail Behavior
 
-PASS when state, design debt, handoff, retrospective, and evidence references are current enough for `ulw-plan`, `start-work`, `visual-qa`, or `review-work` to resume without guessing.
+PASS when state, design debt, handoff, retrospective, and evidence references are current enough for `ulw-plan`, `ulw-execute`, `visual-qa`, or `review-work` to resume without guessing.
 
 FAIL when deferred findings disappear, accessibility debt is accepted without acknowledgement, handoff omits artifact paths, state is stale, retrospective claims lack evidence, or memory is used as prescriptive design input.

package/packages/shared-skills/skills/frontend/references/designpowers/orchestration.md

@@ -51,7 +51,7 @@ When using a designpowers role reference:
 
 - name the role in the prompt text;
 - include a self-contained task, deliverable, scope, and verification expectation;
-- route actual phase ownership to frontend design/perfection, `/ulw-plan`, `/start-work`, `/visual-qa`, or `/review-work`;
+- route actual phase ownership to frontend design/perfection, `/ulw-plan`, `/ulw-execute`, `/visual-qa`, or `/review-work`;
 - record findings in the state file or review packet only when backed by artifacts or located observations.
 
 ## Reconciliation Ladder

package/packages/shared-skills/skills/frontend/references/designpowers/routing.md

@@ -1,13 +1,13 @@
 # designpowers Routing Contract
 
-`designpowers` routes design operating-layer guidance inside the existing frontend skill. It is not a replacement for `/frontend`, `/visual-qa`, `/ulw-plan`, `/start-work`, `/review-work`, or any OpenAgent skill, and it must not create a second planner, builder, verification harness, or orchestration API.
+`designpowers` routes design operating-layer guidance inside the existing frontend skill. It is not a replacement for `/frontend`, `/visual-qa`, `/ulw-plan`, `/ulw-execute`, `/review-work`, or any OpenAgent skill, and it must not create a second planner, builder, verification harness, or orchestration API.
 
 ## Phase Routing
 
 | User intent or workflow phase | Load or instruct | Required handoff from designpowers |
 |---|---|---|
 | Ambiguous or multi-step web UI request; any request needing a plan | `/ulw-plan` plus this reference's `lane-a-direction.md` | Provide design discovery prompts, target users, inclusive personas, taste direction, open owner decisions, and design debt policy as planning inputs. |
-| Approved plan execution; continuing an OpenAgent plan | `/start-work` plus `lane-b-execution.md` | Keep execution under Boulder/ledger discipline and include current design-state constraints in worker assignments. |
+| Approved plan execution; continuing an OpenAgent plan | `/ulw-execute` plus `lane-b-execution.md` | Keep execution under Boulder/ledger discipline and include current design-state constraints in worker assignments. |
 | Building, styling, redesigning, auditing, or performance-checking a web UI | frontend `design` + `perfection`; add `lane-b-execution.md` when designpowers context affects implementation | Preserve the frontend `DESIGN.md` gate, design/perfection routing, React tooling, real-browser checks, and implementation standards. |
 | Screenshots, visual regressions, clone fidelity, layout quality, alpha/CJK checks, or design QA | `/visual-qa` plus `lane-c-review.md` | Run objective evidence capture before design judgment and feed the same artifacts into persona/accessibility/heuristic review. |
 | Final implementation approval, QA my work, review changes, or significant completed implementation | `/review-work` plus `lane-c-review.md` and `lane-d-memory.md` | Include the design brief, state file path, visual artifacts, unresolved design debt, and accessibility-debt acknowledgements as review inputs. |
@@ -25,9 +25,9 @@ When planning is needed, `designpowers` supplies design-specific context and let
 - verification expectations: frontend checks, visual QA artifacts, persona walkthroughs, and review-work sign-off;
 - explicit Must Not Have constraints, including prohibited bridge/canvas tooling.
 
-## Execution Through `/start-work`
+## Execution Through `/ulw-execute`
 
-When a plan is approved or selected, `/start-work` remains the orchestrator. `designpowers` only enriches worker prompts with design context from `.omo/frontend-design/state.md` and the selected plan. Worker prompts should carry:
+When a plan is approved or selected, `/ulw-execute` remains the orchestrator. `designpowers` only enriches worker prompts with design context from `.omo/frontend-design/state.md` and the selected plan. Worker prompts should carry:
 
 - the exact plan checkbox and files in scope;
 - design-state constraints that affect the task;
@@ -35,7 +35,7 @@ When a plan is approved or selected, `/start-work` remains the orchestrator. `de
 - required `/visual-qa` loading for rendered visual proof;
 - the design debt rule: unresolved accessibility debt cannot disappear into a summary.
 
-Direct implementation outside `/start-work` is not part of this routing contract when a Prometheus plan is active.
+Direct implementation outside `/ulw-execute` is not part of this routing contract when a Prometheus plan is active.
 
 ## UI Build Through Frontend `design` And `perfection`
 

package/packages/shared-skills/skills/{start-work → ulw-execute}/SKILL.md

@@ -1,6 +1,6 @@
 ---
-name: start-work
-description: "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."
+name: ulw-execute
+description: "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 ulw-execute, execute plan, continue plan, resume plan, or asks to run a .omo/plans plan."
 ---
 
 ## ABSOLUTE RULE: YOU ARE AN ORCHESTRATOR — NEVER THE IMPLEMENTER
@@ -31,14 +31,14 @@ Every `multi_agent_v1.spawn_agent` message is a self-contained executable assign
 
 Plan and reviewer agents may run for a long time: spawn them in the background and keep doing independent root work. Between `multi_agent_v1.wait_agent` calls, back off — double the timeout up to ~5 minutes — instead of spinning short cycles. A timeout only means no new mailbox update arrived; treat a running child as alive. Require `WORKING: <task> - <current phase>` before long passes and `BLOCKED: <reason>` only when progress stops. Keep the parent visibly alive with active subagent count, names, and latest `WORKING:` phase. Fallback only when the child is completed without the deliverable, ack-only after followup, explicitly `BLOCKED:`, or no longer running — then record inconclusive (never a pass), close if safe, and respawn a smaller `fork_context: false` task with the missing deliverable.
 
-# start-work
+# ulw-execute
 
-Execute a Prometheus work plan until every top-level checkbox is complete. This skill pairs with the harness's start-work continuation hook, which re-injects the next turn while `.omo/boulder.json` says this `codex:<session_id>` still has unchecked plan work.
+Execute a Prometheus work plan until every top-level checkbox is complete. This skill pairs with the harness's ulw-execute continuation hook, which re-injects the next turn while `.omo/boulder.json` says this `codex:<session_id>` still has unchecked plan work.
 
 ## Usage
 
 ```text
-$start-work [plan-name] [--worktree <absolute-path>] [--make-pr] [--ship]
+$ulw-execute [plan-name] [--worktree <absolute-path>] [--make-pr] [--ship]
 ```
 
 - `plan-name` (optional): a full or partial file stem under `.omo/plans/`.
@@ -66,7 +66,7 @@ Do ALL of this immediately after the plan is selected, BEFORE the first implemen
 
 ### No-plan bootstrap
 
-When the user explicitly said `start work` / `$start-work` and no selectable plan exists, treat that phrase as approval: bootstrap `ulw-plan` to create the approved plan before execution and implementation, instead of stalling or asking for generic approval again. A brief or notes file without waves, checkboxes, and acceptance criteria is NOT decision-complete — enter this bootstrap too.
+When the user explicitly said `start work` / `$ulw-execute` and no selectable plan exists, treat that phrase as approval: bootstrap `ulw-plan` to create the approved plan before execution and implementation, instead of stalling or asking for generic approval again. A brief or notes file without waves, checkboxes, and acceptance criteria is NOT decision-complete — enter this bootstrap too.
 
 1. Invoke the `ulw-plan` skill from the current request and require its dynamic adversarial workflow: collect, verify, design, adversarial plan-review, synthesize.
 2. The generated Prometheus plan must be saved under `.omo/plans/<slug>.md` before implementation or Boulder state writes that point at plan work.
@@ -179,7 +179,7 @@ For each checkbox, complete all five gates before marking it done:
 4. Adversarial QA: exercise every class the Phase 3 trigger map marks applicable and capture the observable result for each.
 5. Cleanup: register every QA resource teardown as its own todo when spawned (QA scripts, tmux assets, browser sessions, PIDs, ports, containers, temp dirs), execute each, and capture the receipt. No QA asset is left running.
 
-Append evidence to `.omo/start-work/ledger.jsonl`, one JSON object per line. Include at least `event`, `plan`, `task`, `session_id`, `commands`, `artifact`, `adversarial_classes`, and `cleanup` fields. `adversarial_classes` lists each probed class with its observable result and each ruled-out class with a one-line reason.
+Append evidence to `.omo/ulw-execute/ledger.jsonl`, one JSON object per line. Include at least `event`, `plan`, `task`, `session_id`, `commands`, `artifact`, `adversarial_classes`, and `cleanup` fields. `adversarial_classes` lists each probed class with its observable result and each ruled-out class with a one-line reason.
 
 ### Sisyphus-style completion contract
 

package/packages/shared-skills/skills/ulw-plan/SKILL.md

@@ -9,7 +9,7 @@ metadata:
 
 You are **Prometheus**, a planning consultant. You turn a vague or large request into ONE **decision-complete** work plan a downstream worker executes with zero further interview. You read, search, run read-only analysis, and write ONLY plan artifacts under `.omo/`. You are a PLANNER - you never edit product code and never implement.
 
-**Plan mode is sticky.** "do X" / "fix X" / "build X" / "just do it" all mean "plan X". You **never start implementation** - not for small, obvious, or urgent work, and not through a subagent: delegated implementation is still implementation. Execution belongs to a separate worker session that only the user starts (e.g. `$start-work`).
+**Plan mode is sticky.** "do X" / "fix X" / "build X" / "just do it" all mean "plan X". You **never start implementation** - not for small, obvious, or urgent work, and not through a subagent: delegated implementation is still implementation. Execution belongs to a separate worker session that only the user starts (e.g. `$ulw-execute`).
 
 Outcome-first: explore a lot, ask few sharp questions - or none, when the intent is fuzzy (see routing) - and stop the moment the plan is done.
 
@@ -23,13 +23,13 @@ If another active mode mandates its own first line (ultrawork does), print that
 
 Directly under the marker, before any exploration, state the working contract once, in your own words, carrying ALL of these commitments:
 
-1. **Persona + no-implementation pledge** - from now on you work as Prometheus, a planning consultant, and you will never start implementation - no product-code edits, no implementer subagents - until the user explicitly says okay; even then, approval authorizes writing the plan only, and execution starts in a separate worker session (e.g. `$start-work`).
+1. **Persona + no-implementation pledge** - from now on you work as Prometheus, a planning consultant, and you will never start implementation - no product-code edits, no implementer subagents - until the user explicitly says okay; even then, approval authorizes writing the plan only, and execution starts in a separate worker session (e.g. `$ulw-execute`).
 2. **Workflow preview** - the order of what happens next: parallel read-only exploration (plus outside research when the repo cannot answer) until the open unknowns are resolved; the intent verdict from INTENT ROUTING, announced; questions to the user ONLY when a genuine owner-decision survives exploration - or when exploration and research both come back empty on a fork the plan cannot proceed without; then the approval brief, and the plan is written only after the explicit okay.
 
 Example opening (adapt the wording, keep every commitment):
 
 > ULW-PLAN MODE ENABLED!
-> From now on I am working as Prometheus, a planning consultant. I will not start any implementation until you explicitly say okay - and approval authorizes writing the plan only; execution starts separately (e.g. `$start-work`).
+> From now on I am working as Prometheus, a planning consultant. I will not start any implementation until you explicitly say okay - and approval authorizes writing the plan only; execution starts separately (e.g. `$ulw-execute`).
 > Next, in order: (1) parallel read-only exploration and research, (2) intent verdict announced (CLEAR or UNCLEAR, plus whether high-accuracy review is required), (3) questions only for the forks exploration cannot settle - or where research finds nothing on a blocking decision, (4) approval brief, then (5) the plan is written after your okay.
 
 ## INTENT ROUTING - pick ONE intent reference
@@ -43,7 +43,7 @@ After grounding, make ONE judgment, record `intent: clear|unclear` plus `review_
 
 - **OVERRIDE - explicit ask wins:** if the user explicitly asks to be questioned or interviewed ("ask me", "interview me", "why aren't you asking me" - in any language), route **CLEAR**, run the interview, and turn the adopt-default filter OFF: the user has claimed the forks, so every surviving one is ASKED, not defaulted. This beats the OUTCOME test below, even on a fuzzy brief.
 - **CLEAR** - the user knows the outcome; the only open items are preferences/tradeoffs the repo cannot answer (genuine owner-decisions). Read **`references/intent-clear.md`**: ask the surviving forks with WHY, run the normal approval gate, and offer high-accuracy review only when `review_required` is false.
-- **UNCLEAR** - the outcome itself is fuzzy (a vague brief, a bootstrap, `$start-work` with no selectable plan, a goal the user cannot yet articulate). Asking would offload your own job onto the user. Read **`references/intent-unclear.md`**: research maximally, adopt and ANNOUNCE best-practice defaults, do NOT ask the user extra questions, and, unless Classify sized the work Trivial, set `review_required: true` before the approval gate and run high-accuracy review AUTOMATICALLY.
+- **UNCLEAR** - the outcome itself is fuzzy (a vague brief, a bootstrap, `$ulw-execute` with no selectable plan, a goal the user cannot yet articulate). Asking would offload your own job onto the user. Read **`references/intent-unclear.md`**: research maximally, adopt and ANNOUNCE best-practice defaults, do NOT ask the user extra questions, and, unless Classify sized the work Trivial, set `review_required: true` before the approval gate and run high-accuracy review AUTOMATICALLY.
 - **ON THE FENCE** - when CLEAR vs UNCLEAR is genuinely ambiguous, treat it as CLEAR and ask exactly ONE question. A user wrongly silenced is worse than one extra question. The dominant failure to guard against is mis-routing a CLEAR request to UNCLEAR, which silently applies defaults and overrides forks the user wanted to own.
 
 WORKED: "add a 5/min-per-IP rate-limit to `/login`" = CLEAR. "make auth better" = UNCLEAR.

package/packages/shared-skills/skills/ulw-plan/references/full-workflow.md

@@ -10,7 +10,7 @@ metadata:
 The deep mechanics both routing paths share (`intent-clear.md`, `intent-unclear.md`). Read the phase you are in.
 
 ## Role
-You are Prometheus, a planning consultant. You turn a vague or large request into ONE decision-complete work plan a downstream worker executes with zero further interview. You read, search, run read-only analysis, and write only `.omo/plans/<slug>.md` and `.omo/drafts/*.md`. You never edit product code and never implement - directly or through a subagent. **Plan mode is sticky**: "do X" / "fix X" / "just do it" mean "plan X"; execution belongs to the worker and starts only on the user's explicit start (e.g. `$start-work`), never on your judgment.
+You are Prometheus, a planning consultant. You turn a vague or large request into ONE decision-complete work plan a downstream worker executes with zero further interview. You read, search, run read-only analysis, and write only `.omo/plans/<slug>.md` and `.omo/drafts/*.md`. You never edit product code and never implement - directly or through a subagent. **Plan mode is sticky**: "do X" / "fix X" / "just do it" mean "plan X"; execution belongs to the worker and starts only on the user's explicit start (e.g. `$ulw-execute`), never on your judgment.
 
 ## North star
 A plan is decision-complete when the implementer needs ZERO judgment calls: every decision made, every ambiguity resolved, every pattern referenced with a concrete path. The executor has NO interview context - be exhaustive.
@@ -22,7 +22,7 @@ Size interview depth: **Trivial** (single file, obvious) - one or two confirms,
 Eliminate unknowns by discovering facts, not by asking. Before your first question, fan out parallel read-only research and keep working while it runs. Two kinds of unknowns: **discoverable facts** (repo/system truth) become research-and-cite; **preferences/tradeoffs** (user intent, not derivable from code) are the only things the CLEAR path brings to the user, and the things the UNCLEAR path resolves to best-practice defaults. Retrieval budget: stop exploring a question once collected evidence answers it, or after two research waves add no new useful facts.
 
 ### Dynamic workflow for architecture and bootstrap planning
-When the request is architecture-scale, references Discord / external repos, or is invoked by `$start-work` because no selectable plan exists, run **dynamic adversarial workflow phases** before synthesis. For broad requests, self-orchestrates 5 host subagents so the plan keeps maximum safe parallelism without losing evidence quality:
+When the request is architecture-scale, references Discord / external repos, or is invoked by `$ulw-execute` because no selectable plan exists, run **dynamic adversarial workflow phases** before synthesis. For broad requests, self-orchestrates 5 host subagents so the plan keeps maximum safe parallelism without losing evidence quality:
 1. **collect** lanes: repo implementation surface, tests/package surface, external or Discord claims, execution workflow, risk/QA.
 2. **verify** lanes: each verifier gets routed context from its collect lane and tries to falsify it; return `verdict`, `evidence`, `confidence`.
 3. **design** lanes: turn only verified facts into implementation waves, a dependency matrix, acceptance criteria, and QA artifacts.
@@ -132,7 +132,7 @@ Then read the user's next reply as a decision:
 - **Scope change** - a reply that alters the approach. Fold it into the draft, update the brief, re-present once.
 - **Still unclear** - emit ONE short line naming the pending action and the approval you need; **do not re-explore** and do not restate the whole brief.
 
-No Metis, no plan file, no execution until the user approves. The UNCLEAR path auto-runs the high-accuracy review AFTER approval; it never skips this gate. Narrow `$start-work` bootstrap exception: when `$start-work` invoked this skill because there was no selectable plan, the user's "start work" counts as approval to generate the plan; execution then begins per the harness's start-work rule - never run by the planning agent itself.
+No Metis, no plan file, no execution until the user approves. The UNCLEAR path auto-runs the high-accuracy review AFTER approval; it never skips this gate. Narrow `$ulw-execute` bootstrap exception: when `$ulw-execute` invoked this skill because there was no selectable plan, the user's "start work" counts as approval to generate the plan; execution then begins per the harness's ulw-execute rule - never run by the planning agent itself.
 
 ## Phase 3 - Generate the plan (only after approval)
 1. Rerun `node "<skill-root>/scripts/scaffold-plan.mjs" <slug> [--clear|--unclear]` without `--draft-only`. The existing draft is preserved and the plan skeleton is created now, after approval. A plain rerun is a safe no-op; never hand-build the skeleton.
@@ -177,7 +177,7 @@ Every "present the plan summary/brief" above delivers THIS structure, in the use
 3. **Shape** - how many phases/waves and how many tasks: N implementation todos (`- [ ] N.` rows) + F final-verification tasks (`- [ ] F<n>.` rows), plus the executor-category mix (e.g. 6x `quick`, 2x `unspecified-high`, 1x `ultrabrain`).
 4. **Added beyond the request** - what exploration surfaced and you folded in that the user never explicitly asked for (edge cases, migrations, tests, rollback, docs), each with a one-line reason; say "none" if nothing was added.
 5. **Verification** - how completion will be proven: the final verification wave plus the key QA scenarios/commands.
-6. **Execution handoff** - the plan runs in a worker session via `$start-work <plan-name>`; introduce the options: `--worktree <absolute-path>` (task-owned worktree; required for PR/branch work), `--make-pr` (deliver as a PR; auto-creates a task-owned worktree), `--ship` (implies `--make-pr`, keeps working until the PR is reviewed and MERGED).
+6. **Execution handoff** - the plan runs in a worker session via `$ulw-execute <plan-name>`; introduce the options: `--worktree <absolute-path>` (task-owned worktree; required for PR/branch work), `--make-pr` (deliver as a PR; auto-creates a task-owned worktree), `--ship` (implies `--make-pr`, keeps working until the PR is reviewed and MERGED).
 
 ### High-accuracy review (dual review)
 The high-accuracy review is DUAL and both passes must return OKAY before handoff: (1) the native `momus` reviewer subagent, and (2) an independent Oracle review via `task(subagent_type="oracle", ...)` on the strongest available reasoning model, in a fully isolated sub-session with normal approval and sandbox policy. Do not add flags that disable approvals or sandboxing. Momus runs at High and may take substantially longer than other agents. One round = exactly ONE `momus` + ONE independent review, dispatched together against the COMPLETE plan file (todos + TL;DR filled) at the draft's exact recorded `plan_path`. Keep Momus in flight and wait for its terminal result: elapsed time alone never justifies cancelling, duplicating, replacing, or treating it as failed. After both verdicts return, fix every eligible blocker and resubmit both fresh under the bounded convergence contract below; ineligible findings become non-blocking notes. CLEAR: runs when the user opts in or `review_required: true`. UNCLEAR: runs automatically unless Classify=Trivial.

package/packages/shared-skills/skills/ulw-plan/references/intent-unclear.md

@@ -7,7 +7,7 @@ metadata:
 
 # ulw-plan - UNCLEAR intent
 
-Read this when INTENT ROUTING resolved to UNCLEAR: the desired OUTCOME is fuzzy - a vague request, a bootstrap, `$start-work` with no selectable plan, or a goal the user cannot yet articulate. Asking the user to resolve it would offload the planner's own job onto them.
+Read this when INTENT ROUTING resolved to UNCLEAR: the desired OUTCOME is fuzzy - a vague request, a bootstrap, `$ulw-execute` with no selectable plan, or a goal the user cannot yet articulate. Asking the user to resolve it would offload the planner's own job onto them.
 
 <stance>
 PRIME DIRECTIVE: do NOT interrogate the user. Resolve ambiguity by RESEARCH, not questions. You are a consultant who does the homework and ANNOUNCES loud best-practice defaults, not a form to fill in. The user's time is spent only on a genuinely irreversible, destructive, or safety-critical fork that research cannot settle - then exactly one focused question. Everything else you answer yourself from evidence plus best practice; the user vetoes at the gate via the human TL;DR, not via an interview.
@@ -32,7 +32,7 @@ TRIVIAL-TIER GUARD: if Classify sized the work Trivial, the auto-Momus loop is S
 </high_accuracy_auto>
 
 <approval_gate>
-Still present a brief and wait for the user's explicit okay - approval is not execution - but the brief LEADS with "here is the best-practice approach I derived and the assumptions I adopted (with reversibility)", not "here are questions for you". The adopted-defaults list is surfaced loudly in the plan's human TL;DR "Decisions I made for you" block, so the user can veto any single default at the gate. LEAD that block with the routing call itself - "I treated this as open-ended and chose defaults; if you had a specific outcome in mind, say so and I will switch to asking" - so a wrong CLEAR-as-UNCLEAR read is a one-line correction at the gate, not a silently-spent adversarial loop. Approval authorizes writing or keeping the plan only, never implementation. The durable draft (Components plus Open-assumptions ledgers plus gate state) is the compaction-safe resume point. ($start-work bootstrap exception: "start work" counts as approval to generate the plan, with execution starting per the harness's start-work rule - never run by the planning agent itself; ordinary ulw-plan keeps the normal gate.)
+Still present a brief and wait for the user's explicit okay - approval is not execution - but the brief LEADS with "here is the best-practice approach I derived and the assumptions I adopted (with reversibility)", not "here are questions for you". The adopted-defaults list is surfaced loudly in the plan's human TL;DR "Decisions I made for you" block, so the user can veto any single default at the gate. LEAD that block with the routing call itself - "I treated this as open-ended and chose defaults; if you had a specific outcome in mind, say so and I will switch to asking" - so a wrong CLEAR-as-UNCLEAR read is a one-line correction at the gate, not a silently-spent adversarial loop. Approval authorizes writing or keeping the plan only, never implementation. The durable draft (Components plus Open-assumptions ledgers plus gate state) is the compaction-safe resume point. ($ulw-execute bootstrap exception: "start work" counts as approval to generate the plan, with execution starting per the harness's ulw-execute rule - never run by the planning agent itself; ordinary ulw-plan keeps the normal gate.)
 </approval_gate>
 
 <worked_example>

package/dist/config/schema/start-work.d.ts

@@ -1,5 +0,0 @@
-import { z } from "zod";
-export declare const StartWorkConfigSchema: z.ZodObject<{
-    auto_commit: z.ZodDefault<z.ZodBoolean>;
-}, z.core.$strip>;
-export type StartWorkConfig = z.infer<typeof StartWorkConfigSchema>;

package/dist/features/builtin-commands/templates/start-work.d.ts

@@ -1 +0,0 @@
-export declare const START_WORK_TEMPLATE = "You are starting an Atlas work session.\n\n## ARGUMENTS\n\n- `/start-work [plan-name] [--worktree <path>] [--make-pr] [--ship]`\n  - `plan-name` (optional): name or partial match of the plan to start\n  - `--worktree <path>` (optional): absolute path to an existing git worktree to work in\n    - If specified and valid: hook pre-sets worktree_path in boulder.json\n    - If specified but invalid: you must run `git worktree add <path> <branch>` first\n    - If omitted: work directly in the current project directory (no worktree)\n  - `--make-pr` (optional): deliver the work as a pull request. IMPLIES worktree mode - when `--worktree` is omitted, create a task-owned worktree before implementation. On completion push the branch, open a reviewer-readable PR, and hand off with the PR URL (merge only on explicit user ask)\n  - `--ship` (optional): full delivery lifecycle; implies `--make-pr`. After the PR opens, keep working until it is MERGED (CI + review gates, feedback addressed), then clean up the worktree and sync `.omo/` state back\n\n## WHAT TO DO\n\n1. **Find available plans**: Search for Prometheus-generated plan files at `.omo/plans/`\n\n2. **Check for active boulder state**: Read `.omo/boulder.json` if it exists\n\n3. **Decision logic**:\n   - If multiple active works are listed in your context:\n     - This means boulder.json has more than one work with status: `active` or `paused`\n     - Use the Question tool to ask the user which plan to resume\n     - Resume by running `/start-work {plan-name}` for the selected plan\n     - If the user says \"start a new plan\", continue with cold-start auto-selection logic\n   - If exactly one active work is listed and the user did not name a plan:\n     - Auto-resume that single active work\n   - If no active plan OR plan is complete:\n     - List available plan files\n     - If ONE plan: auto-select it\n     - If MULTIPLE plans: show list with timestamps, ask user to select\n\n4. **Worktree Setup** (ONLY when `--worktree` was explicitly specified and `worktree_path` not already set in boulder.json):\n   1. `git worktree list --porcelain` - see available worktrees\n   2. Create: `git worktree add <absolute-path> <branch-or-HEAD>`\n   3. Update boulder.json to add `\"worktree_path\": \"<absolute-path>\"`\n   4. All work happens inside that worktree directory\n\n5. **Create/Update boulder.json**:\n   ```json\n   {\n     \"active_plan\": \"/absolute/path/to/plan.md\",\n     \"started_at\": \"ISO_TIMESTAMP\",\n     \"session_ids\": [\"session_id_1\", \"session_id_2\"],\n     \"plan_name\": \"plan-name\",\n     \"worktree_path\": \"/absolute/path/to/git/worktree\"\n   }\n   ```\n\n6. **Read the plan file** and start executing tasks according to atlas workflow\n\n## OUTPUT FORMAT\n\nWhen listing plans for selection:\n```\nAvailable Work Plans\n\nCurrent Time: {ISO timestamp}\nSession ID: {current session id}\n\n1. [plan-name-1.md] - Modified: {date} - Progress: 3/10 tasks\n2. [plan-name-2.md] - Modified: {date} - Progress: 0/5 tasks\n\nWhich plan would you like to work on? (Enter number or plan name)\n```\n\nWhen resuming existing work:\n```\nResuming Work Session\n\nActive Plan: {plan-name}\nProgress: {completed}/{total} tasks\nSessions: {count} (appending current session)\nWorktree: {worktree_path}\n\nReading plan and continuing from last incomplete task...\n```\n\nWhen auto-selecting single plan:\n```\nStarting Work Session\n\nPlan: {plan-name}\nSession ID: {session_id}\nStarted: {timestamp}\nWorktree: {worktree_path}\n\nReading plan and beginning execution...\n```\n\n## CRITICAL\n\n- The session_id is injected by the hook - use it directly\n- Always update boulder.json BEFORE starting work\n- If worktree_path is set in boulder.json, all work happens inside that worktree directory\n- Read the FULL plan file before delegating any tasks\n- Follow atlas delegation protocols (7-section format)\n\n## GOAL + TASK BREAKDOWN (MANDATORY)\n\nDo BOTH of these immediately after reading the plan file, BEFORE starting any work. Skipping either is a defect.\n\n**1. Set the goal, in detail.** When a goal tool is available (`create_goal`), call it with a DETAILED objective: the plan name and path, the concrete end state, the phase/task counts, the delivery mode (direct, `--make-pr`, or `--ship`), and how completion will be verified. One work session = one goal. No goal tool -> record the same objective as the first `.omo/start-work/ledger.jsonl` entry.\n\n**2. Register every phase and task as todos.** Decompose every plan task into granular, implementation-level sub-steps and register ALL of them as task/todo items, grouped phase by phase (one phase per plan wave), BEFORE starting any work. Keep them current at every moment: mark in_progress when work dispatches and done immediately after its verification passes - never batch-complete at the end, never execute work that is not a registered todo. Discovered work is appended as a todo before it runs.\n\n**How to break down**:\n- Each plan checkbox item (e.g., `- [ ] Add user authentication`) must be split into concrete, actionable sub-tasks\n- Sub-tasks should be specific enough that each one touches a clear set of files/functions\n- Include: file to modify, what to change, expected behavior, and how to verify\n- Do NOT leave any task vague - \"implement feature X\" is NOT acceptable; \"add validateToken() to src/auth/middleware.ts that checks JWT expiry and returns 401\" IS acceptable\n\n**Example breakdown**:\nPlan task: `- [ ] Add rate limiting to API`\n\u2192 Todo items:\n  1. Create `src/middleware/rate-limiter.ts` with sliding window algorithm (max 100 req/min per IP)\n  2. Add RateLimiter middleware to `src/app.ts` router chain, before auth middleware\n  3. Add rate limit headers (X-RateLimit-Limit, X-RateLimit-Remaining) to response in `rate-limiter.ts`\n  4. Add test: verify 429 response after exceeding limit in `src/middleware/rate-limiter.test.ts`\n  5. Add test: verify headers are present on normal responses\n\nRegister these as task/todo items so progress is tracked and visible throughout the session.\n\n## WORKTREE COMPLETION\n\nWhen working in a worktree (`worktree_path` is set in boulder.json) and ALL plan tasks are complete:\n1. Commit all remaining changes in the worktree\n2. **Sync .omo state back**: Copy `.omo/` from the worktree to the main repo before removal.\n   This is CRITICAL when `.omo/` is gitignored - state written during worktree execution would otherwise be lost.\n   ```bash\n   cp -r <worktree-path>/.omo/* <main-repo>/.omo/ 2>/dev/null || true\n   ```\n3. Switch to the main working directory (the original repo, NOT the worktree)\n4. Merge the worktree branch into the current branch: `git merge <worktree-branch>`\n5. If merge succeeds, clean up: `git worktree remove <worktree-path>`\n6. Remove the boulder.json state\n\nThis is the DEFAULT behavior when `--worktree` was used alone. When `--make-pr` or `--ship` is active, skip the local merge and follow the PR Delivery Mode instructions in the session context instead: push the branch and open a PR (`--make-pr` hands off with the PR URL; `--ship` keeps working until the PR is merged), then clean up. Otherwise skip merge only if the user explicitly instructs otherwise (e.g., asks to create a PR instead).";