@difflab/pi 0.7.0 → 0.7.1

package/dist/tools/modes.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"modes.d.ts","sourceRoot":"","sources":["../../src/tools/modes.ts"],"names":[],"mappings":"AAAA,OAAO,EAAc,KAAK,cAAc,EAAE,MAAM,iCAAiC,CAAC;AAGlF,OAAO,KAAK,EAAe,cAAc,EAAE,MAAM,UAAU,CAAC;AAiB5D,wBAAgB,eAAe,CAAC,UAAU,EAAE,cAAc,GAAG,SAAS,cAAc,EAAE,CAiErF"}
+{"version":3,"file":"modes.d.ts","sourceRoot":"","sources":["../../src/tools/modes.ts"],"names":[],"mappings":"AAAA,OAAO,EAAc,KAAK,cAAc,EAAE,MAAM,iCAAiC,CAAC;AAGlF,OAAO,KAAK,EAAe,cAAc,EAAE,MAAM,UAAU,CAAC;AAiB5D,wBAAgB,eAAe,CAAC,UAAU,EAAE,cAAc,GAAG,SAAS,cAAc,EAAE,CAiFrF"}

package/dist/tools/plan.d.ts

@@ -1,6 +1,4 @@
-import type { ExtensionAPI, ToolDefinition } from '@earendil-works/pi-coding-agent';
-import type { ModeController } from '../modes';
-import { type PlanStore } from '../plan/store';
-export type PlanToolRuntime = Pick<ExtensionAPI, 'events' | 'sendUserMessage'> & Partial<Pick<ExtensionAPI, 'sendMessage'>>;
-export declare function createPlanTools(_pi: PlanToolRuntime, _modes: ModeController, store?: PlanStore): readonly ToolDefinition[];
+import { type ToolDefinition } from '@earendil-works/pi-coding-agent';
+/** Mechanical checks only; independent human-quality review remains required. */
+export declare const planVerifyTool: ToolDefinition;
 //# sourceMappingURL=plan.d.ts.map

package/dist/tools/plan.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"plan.d.ts","sourceRoot":"","sources":["../../src/tools/plan.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,YAAY,EAAE,cAAc,EAAE,MAAM,iCAAiC,CAAC;AAQpF,OAAO,KAAK,EAAE,cAAc,EAAE,MAAM,UAAU,CAAC;AAM/C,OAAO,EAAmB,KAAK,SAAS,EAAE,MAAM,eAAe,CAAC;AAchE,MAAM,MAAM,eAAe,GAAG,IAAI,CAAC,YAAY,EAAE,QAAQ,GAAG,iBAAiB,CAAC,GAC5E,OAAO,CAAC,IAAI,CAAC,YAAY,EAAE,aAAa,CAAC,CAAC,CAAC;AAE7C,wBAAgB,eAAe,CAC7B,GAAG,EAAE,eAAe,EACpB,MAAM,EAAE,cAAc,EACtB,KAAK,GAAE,SAA6B,GACnC,SAAS,cAAc,EAAE,CAkR3B"}
+{"version":3,"file":"plan.d.ts","sourceRoot":"","sources":["../../src/tools/plan.ts"],"names":[],"mappings":"AAAA,OAAO,EAAc,KAAK,cAAc,EAAE,MAAM,iCAAiC,CAAC;AAMlF,iFAAiF;AACjF,eAAO,MAAM,cAAc,EAAE,cAoB3B,CAAC"}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@difflab/pi",
-  "version": "0.7.0",
+  "version": "0.7.1",
   "description": "Tools and skills for the pi coding agent",
   "repository": {
     "type": "git",

package/skills/mode/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: mode
 description: List, select, or clear an inline agent profile. Use when the user invokes /skill:mode or asks to change the current Diffpi mode.
-allowed-tools: ask_user_question diffpi_modes_list diffpi_modes_set diffpi_modes_unset
+allowed-tools: ask_user_question diffpi_modes_list diffpi_modes_set diffpi_modes_unset diffpi_modes_status
 ---
 
 # Mode
@@ -12,7 +12,7 @@ Pi appends `/skill:mode` arguments as `User: <arguments>`. Route those arguments
 
 - If the argument is `help`, `-h`, or `--help`, print the usage and examples below. Do not call a tool.
 - If the argument is `clear`, call `diffpi_modes_unset` and stop.
-- If the argument is one agent id, call `diffpi_modes_set` with that exact id and stop.
+- If the argument is one agent id, call `diffpi_modes_set` with that exact id. On the next model turn, call `diffpi_modes_status` to verify the selected model, thinking level, and active tools; if preflight or verification fails, report the exact capability error and do not claim an active mode.
 - A qualified id such as `spec:planner` is one agent id. The tool enables skill-agent discovery for it.
 - If the request contains multiple agent ids or an unsupported flag, print the usage and stop.
 
@@ -33,6 +33,6 @@ Use the picker when there are no arguments or when the only argument is `--inclu
 2. Call `ask_user_question` with one single-select question. Do not ask as plain chat text.
 3. Put the complete list of valid ids in the question text. Offer Default plus at most three relevant agents as structured options. The custom-answer row lets the user enter any other valid id.
 4. If the user selects Default or enters `clear`, call `diffpi_modes_unset`.
-5. Otherwise, call `diffpi_modes_set` with the selected or entered id.
+5. Otherwise, call `diffpi_modes_set` with the selected or entered id. On the next model turn, call `diffpi_modes_status` and verify the selected model, thinking level, and active tools. If selection or post-turn verification fails, report the exact capability error and ensure no ghost active mode is claimed.
 
 Do not perform unrelated work. Explain that the selected prompt, preferred available model, thinking level, and tool set start on the next turn. Mode selection is not a security boundary.

package/skills/plan/SKILL.md

@@ -1,17 +1,31 @@
 ---
 name: plan
-description: Create, revise, annotate, finalize, and execute durable Diffpi plans. Use for /skill:plan, /plan, or natural-language planning requests.
-allowed-tools: read grep find symbol_search module_report read_symbol ask_user_question Agent get_subagent_result steer_subagent plan_context plan_init plan_apply_revision plan_validate plan_review plan_annotate plan_start_execution plan_update_status plan_log_progress plan_run_gates plan_record_ci watch_ci
+description: Create, revise, review, finalize, and execute live Diffpi plans with direct files and one verified plan reviewer.
+allowed-tools: read grep find write edit ask_user_question Agent get_subagent_result steer_subagent diffpi_modes_set diffpi_modes_status plan_verify bash ctx_execute ctx_execute_file watch_ci
 ---
 
 # Plan
 
-This skill owns the workflow. `/plan` only forwards its raw arguments to `/skill:plan`. Do not emit another command to paste or rely on a command handler to select an agent, parse flags, or inject a workflow. Call plan tools directly; never edit managed PLAN.md, implementation briefs, revisions, reviews, or logs with file tools.
+`/plan` forwards raw arguments to this skill. Parse the first explicit verb (`init`, `new`, `update`, `annotate`, `finalize`, `go`, `help`); for unknown or empty input, infer a verb from a clear natural-language request. Use `help` only when neither verb nor intent is identifiable; when plan/intent is ambiguous, ask one structured material-decision question. Preserve the exact incoming user request for the Planner. Read the matching reference first. Keep the alias handler thin. Git and project tasks run through `bash` (or the upstream git skill); do not invent tool names for tasks, format, lint, test, CI, or push.
 
-Identify the first explicit verb (`init`, `new`, `update`, `annotate`, `finalize`, `go`, `help`) or infer one from the user's request. If the verb or required plan is ambiguous, call `plan_context` and ask only for a material decision using `ask_user_question`. Read exactly the corresponding [workflow reference](references/workflows/) before acting. Preserve the exact incoming user request (and applied review feedback) as revision input; do not paraphrase it.
+## Roles and preflight
 
-`new` creates a complete plan without launching an editor; `init` creates a phase-less draft and opens it. For content changes, build a complete candidate and apply it **once per user request** with `plan_apply_revision`. Phase/task status and gates use their dedicated tools and do not constitute a new content revision. Strict `plan_validate` checks document and brief structure, not whether source code implements the plan. `go` calls `plan_start_execution` before any code change; if the plan is draft or on the wrong branch, stop.
+- **Planner** authors and repairs live `PLAN.md` and numbered briefs with frontier/high thinking.
+- **diffpi-plan-reviewer** is exactly one independent frontier/high, read/search-only child. It first calls `diffpi_modes_status` and returns actual model, thinking, and tools evidence, then reviews structure, parity, action labels, quality, risk, and Worker executability. Reject missing or unverifiable evidence; do not use a fallback reviewer.
+- **Orchestrator** owns go coordination, live-file checkboxes/status, project gates, Git, push, and CI. **Worker** edits only its declared source/test scope and never changes plan files or commits.
 
-`--bg` requests one named background agent through `Agent` (Planner for authoring, Orchestrator for execution); pass the verb, exact arguments, cwd, and a `background: true` instruction. Remove `--bg` from the child's request and explicitly forbid redispatch. Return after launching it. A background child must not ask user questions. If `Agent` is unavailable, stop and report that background execution cannot be started; never silently execute inline. Without `--bg`, execute in the current turn: author as Planner, coordinate go as Orchestrator and delegate bounded Worker tasks; do not assume an inline mode switch occurred. Do not launch a multi-agent workflow unless the user explicitly opts into one.
+For foreground authoring, call `diffpi_modes_set({agent: "planner"})` using the shared inline id (never `plan:planner`); on the next model turn call `diffpi_modes_status` and stop if the switch or evidence is unavailable. For foreground `go`, call `diffpi_modes_set({agent: "orchestrator"})` and verify its status on the next turn. `--bg` launches exactly one named same-session child with `Agent` (Planner for `init/new/update/finalize`, Orchestrator for `go`), passing the exact verb, target, cwd, mode, and `background: true`; remove `--bg`. The child never redispatches, asks questions, or falls back inline.
 
-Operational references: [init](references/workflows/init.md), [new](references/workflows/new.md), [update](references/workflows/update.md), [annotate](references/workflows/annotate.md), [finalize](references/workflows/finalize.md), [go](references/workflows/go.md), [help](references/workflows/help.md).
+## Live-file contract
+
+Plans live under the initiating nested Git root in one flat `.diffpi/plan/<YYMMDD[-ticket]-short-slug>/` directory. The date and slug are parts of ONE directory name, never nested `date/slug` directories. Resolve collisions before writing. Use ordinary `read`/`write`/`edit` calls, read every file back, and preserve intent, IDs, completed evidence, order, dependencies, scopes, and constraints. Document phase constraints in each phase's `PLAN.md` entry (use `None` if empty). Each brief puts its sole action-labeled, fenced `text` file tree under `## Files Affected` immediately after `## Objective` (never a bullet list); `## Implementation Constraints` is free-form with optional subheadings. Edit only live plan files; never managed records, plugin source, tests, or profiles. `INCOMPLETE` is a visible marker inside an open `DRAFT`, not a status enum.
+
+`new` and `update` run the stateless read-only `plan_verify` on the current files, then review the complete current draft with one reviewer profile. Repair actionable findings, rerun mechanical verification after each repair, and invoke the same named reviewer again in a fresh `Agent` call (never resume a finished child) within bounded attempts. They remain `DRAFT` after a successful review. Require the child to complete with an attested explicit PASS; partial, steered, stopped, missing, and BLOCKING reports never count. `finalize` and draft `go` write `READY` only after both a passing `plan_verify` on current files and that completed reviewer PASS; do not dispatch Workers or write ready after repairing a failed review without a new completed review. An already-ready plan is reread and mechanically verified too. `plan_verify` does not judge quality, change status, freeze files, or replace the reviewer. No retired managed-plan tools.
+
+## Execution
+
+`go --mode no-commit|commit|push` defaults to `no-commit`. The Orchestrator is the only writer of plan status/checkboxes and coordinates Workers. A draft gets one mechanical `plan_verify` check and one reviewer per pass; both must pass on current files before ready. Schedule a phase only after all prerequisites complete; derive each bounded Worker's task scope from its steps and the phase's sole Files Affected tree. Serialize tasks with overlapping or uncertain derived scopes; independent tasks may run concurrently only when scopes are unambiguously disjoint and prerequisites are satisfied. Run project format, lint, test, and CI checks via `bash`/`ctx_execute` as appropriate. On any failure, preserve the exact command/output, attempts, and affected role and block.
+
+With `commit`, after gates pass make one phase commit. With `push`, push it and call `watch_ci` for that exact SHA; do not push the next phase until settled. `--bg` has one child only and that child does not redispatch. No stateful plan tools.
+
+Read: [init](references/workflows/init.md), [new](references/workflows/new.md), [update](references/workflows/update.md), [annotate](references/workflows/annotate.md), [finalize](references/workflows/finalize.md), [go](references/workflows/go.md), [help](references/workflows/help.md).

package/skills/plan/references/design-quality.md

@@ -1,41 +1,29 @@
 # Plan authoring quality
 
-Build the design from repository evidence, not generic slogans. Keep it concise enough to scan, but never shrink a section into an uninformative one-line paragraph just to reach a word count.
+Build from repository evidence. Keep the result compact and useful to a Worker.
 
-## Big Ideas
+## PLAN.md
 
-Use outcome-oriented bullets. Each bullet says what will become different and why it belongs in this plan; do not repeat the phase titles. For example:
+- Keep intent, requirements, design, references, and numbered phases in `PLAN.md`.
+- Give each phase a stable ID, title, objective, prerequisites, and documented phase-wide guardrails (use `None` if there are none). Prerequisites and phase constraints belong in `PLAN.md` only; keep detailed technology, algorithm, and invariant instructions for the brief instead of copying them into both places.
+- Put each discrete implementation action in a flat task checkbox with a stable task ID and title. Do not put dependency metadata, steps, file scopes, or acceptance criteria under the checkbox.
+- Preserve phase/task ID and order parity in every implementation brief.
 
-- Keep task status and phase ordering in `PLAN.md` so readers can see progress without reading implementation instructions.
-- Write one numbered brief per phase so Workers receive concrete steps and file/API contracts.
-- Reject incomplete briefs at finalization instead of handing placeholders to execution agents.
+## Implementation brief
 
-## Key API Addition/Updates
+- Give tasks ordered implementation steps. Add nested `Verify` bullets under the relevant task; verification is part of the task, not a separate task.
+- Put `## Files Affected` immediately after `## Objective` and before `## Tasks`. It is the sole phase-level file scope: include exactly one fenced `text` file tree with a directory root and branches whose file leaves start with `[ADD]`, `[MODIFY]`, `[REMOVE]`, `[MOVE from: old/path]`, or `[VERIFY]`. Do not replace the tree with Markdown bullets or add per-task file scopes. Include acceptance criteria for every task.
+- Write `## Implementation Constraints` as useful free-form implementation guidance. Add `### Required Libraries & Technology Choices`, `### Key Algorithm Specifications`, or `### Core Invariants` only when useful; do not require any of them. Do not restate or paraphrase the phase-wide guardrails in `PLAN.md` here; refer to the phase ID when a connection is needed.
+- Read back each file after writing it. Normal successive write/edit calls are intentional: incomplete drafts remain visible until the plan is ready.
 
-Use explanatory paragraphs and illustrative fenced examples showing the actual public call and data contract. Explain which previous call is removed, who calls the new API, what arguments/return value mean, and how errors are surfaced. Do not invent details that the repository has not established; call out a genuine unresolved choice instead. For example:
+## Review and repair
 
-```ts
-await plan_apply_revision({
-  mode: 'amend', // use 'create' with shortSlug instead for revision 0
-  plan,
-  expectedPlanRevision,
-  request: { kind: 'user', text: exactRequest },
-  title,
-  intent,
-  requirements,
-  design: { bigIdeas, keyApiUpdates, consequences },
-  references,
-  phases,
-  briefs,
-});
-```
+Template metadata such as managed revisions or snapshots is not part of the live-file contract. Leave historical plan files untouched; current plans use the direct-file format.
 
-Follow the example with a paragraph describing revision creation and validation, then another covering old mutators or callers being replaced. `mode: 'create'` instead takes `shortSlug` (and optional branch/issue fields) and writes revision 0 directly; `mode: 'amend'` takes `plan` and `expectedPlanRevision` and writes the next revision. Both modes require the same `request`, overview fields, ordered `phases`, and matching `briefs`; there is no `inputs` field and no separate `complete` field. If no public API changes, say so explicitly and show the relevant internal interface or data flow instead.
+After writing the current `PLAN.md` and all numbered briefs, independently invoke exactly one VERIFIED frontier/high-thinking `diffpi-plan-reviewer` in read-only mode. The reviewer checks structure and parity, action labels, whole-plan quality, consistency and risk, and whether every task is executable by a lightweight Worker without guessing, in one pass. Do not replace this with cheap separate reviewers or tiered checks.
 
-## Consequences
+The Planner repairs actionable findings and reruns the same reviewer within bounded attempts. A passing review does not prove that source code implements the plan. `annotate` is optional human review; it does not replace the automated reviewer.
 
-Write distinct before/after paragraphs: how a user invokes the workflow, what a client or Worker reads/calls, and how failure looks. Describe concrete behavior: editor launch, status transitions, validation, snapshots, and review visibility as applicable. Include at least one trade-off, such as storage cost or compatibility break; do not substitute a generic maintainability claim.
+## Contracts and consequences
 
-## PLAN.md versus briefs
-
-Under each PLAN.md phase, make **each discrete implementation action a separate stable task checkbox**. Do not embed Steps, File scopes, or Acceptance criteria below its checkbox. In `implementation/phase-<ordinal>.md`, relist every stable task ID and title and provide ordered implementation steps, exact affected files, API/data-contract changes, algorithms/libraries, constraints, and acceptance criteria. A lightweight Worker must be able to implement the task from the brief without guessing. Before finalization, inspect each rendered brief and require strict validation; no scaffold comments or “define during implementation” placeholders are acceptable.
+Describe real API or data-flow changes. If there is no public API change, say so and show the relevant internal contract. Explain before/after invocation, what readers or Workers consume, validation and failure visibility, and at least one concrete trade-off. Do not use scaffold placeholders in a plan marked ready.

package/skills/plan/references/workflows/annotate.md

@@ -1,11 +1,7 @@
 # `/plan annotate`
 
-## PLAN.md task
+**Owner/tier:** Human, interactive/read-only coordinator. **Tools:** tuicr `--file` or direct-file review plus read. **Children:** none; no automatic reviewer.
 
-Review the selected plan in tuicr and save one immutable review.
+Open the selected live plan in tuicr with `--file`, or conduct a direct-file human review. Keep comments tied to current PLAN.md/brief paths. The human decides whether to apply edits; if edits are requested, return to `/plan update` or `/plan finalize` explicitly.
 
-## Brief
-
-1. Call `plan_context` and resolve the exact plan ID from the slug or conversation; ask the user only if candidates remain ambiguous.
-2. Call `plan_annotate` using the plan file; it owns the tuicr session and review artifact.
-3. Report the selected plan, launch result, and copyable fallback command. Tell the user to run `/plan update <plan-id>` after closing tuicr.
+**Effects:** only the human review artifact/comments may change. **Failure:** report the exact file or tuicr error and leave plan files unchanged. Do not rewrite, dispatch, mark ready, or run an automated second pass.

package/skills/plan/references/workflows/finalize.md

@@ -1,7 +1,10 @@
-# Finalize
+# `/plan finalize`
 
-1. Call `plan_context` to resolve exactly one persisted plan. Call `plan_review` once for that plan and revision. If a current annotation exists, incorporate its exact feedback as one content request through `plan_apply_revision` before finalizing; do not mutate the plan per individual comment. A stale review must not be applied.
-2. Call `plan_validate` with `strict: true` on the resulting revision. Stop if any error remains; this validates plan structure, detailed briefs, and revision snapshots, **not implementation correctness**. Do not mark a plan with empty briefs ready.
-3. Call `plan_update_status` to mark the draft `ready`. Do not call `plan_start_execution` until the user chooses execution.
-4. In foreground mode, use one `ask_user_question` for next action (execute now in foreground/background, later, or keep planning); if executing, also obtain commit mode (`no-commit`, `commit`, or `push`; default `no-commit` if already specified). If they choose execution, follow the [go workflow](go.md) directly in the selected mode; background execution launches one child, not another slash command. If they choose later or planning, return the ready state. Background finalization cannot ask and must leave execution for an explicit request.
-5. No inline mode was selected by a command, so do not unset one as a side effect of finalization.
+**Owner/tier:** Planner, frontier/high. **Tools:** read/write/edit, `diffpi_modes_set`, `diffpi_modes_status`, `plan_verify`, Agent, get_subagent_result, steer_subagent. **Child:** exactly one independent `diffpi-plan-reviewer`, frontier/high, read/search-only.
+
+1. Select the shared inline profile with `diffpi_modes_set({agent: "planner"})` (not `plan:planner`) and verify `diffpi_modes_status` on the next turn; stop on unavailable switch or unverifiable evidence.
+2. Select one live plan. Reread `PLAN.md` and all numbered briefs.
+3. Run read-only `plan_verify` and repair any structural issues. Invoke exactly one reviewer for structure/parity, action labels, quality/risk, consistency, and Worker executability. Verify its attestation before trusting the report.
+4. If findings are actionable, repair the live files, rerun `plan_verify`, and invoke the same named reviewer profile again with a fresh `Agent` call (not `resume`) within bounded attempts. Only after a current mechanical PASS and a completed attested reviewer PASS, write `READY` to `PLAN.md`.
+
+**Effects:** only direct plan repairs and the `READY` marker change. Do not execute or freeze files. **Failure:** preserve evidence and remain `DRAFT`; report exact reviewer/preflight/error details. No fallback, redispatch, background questions, or retired plan tools.

package/skills/plan/references/workflows/go.md

@@ -1,8 +1,11 @@
-# Go
+# `/plan go`
 
-1. Call `plan_context` with the supplied slug. Accept only `no-commit`, `commit`, or `push`; omitted `--mode` means `no-commit`. Do not ask for a mode if the user already chose it.
-2. If the resolved plan is `draft`, finalize it inline before execution: call `plan_review` for the current revision and consume only a current review (apply its exact feedback as one `plan_apply_revision` amend when present; ignore stale reviews), then call `plan_validate` with `strict: true`. If validation passes, call `plan_update_status` for the plan from `draft` to `ready`. Do not invoke the finalize workflow or ask its next-action question. An already `ready` or `blocked` plan needs no review or readiness transition; pass it to `plan_start_execution`, which owns restart and blocker eligibility checks.
-3. Call `plan_start_execution` **before** modifying source, delegating work, or running gates. This enforces ready/blocked status, correct branch, clean worktree when committing, and durable execution ownership. On failure, stop and report the exact blocker; never implement a draft plan speculatively.
-4. Use the returned execution ID and packet. Read the complete phase briefs, assign bounded tasks in dependency order to Workers, and track progress and status through plan tools. Workers do not commit or restructure the plan. Run `plan_run_gates` when a phase's tasks are complete. Failed gates block that phase until repaired and rerun.
-5. In `no-commit`, make no commits or pushes. In `commit`, commit once per phase **after** gates pass; do not push or watch CI. In `push`, push each gated phase commit and monitor CI for its exact SHA, collecting the monitor before the next push and all monitors before completion. Persist the observed commit/CI metadata through plan tools.
-6. Complete the plan only after every task, phase, gate, and required CI settles. Report execution ID, mode, and evidence. Background execution must not affect foreground mode; foreground execution does not require a mode reset because this skill did not select one.
+**Owner/tier:** Orchestrator, medium. **Tools:** read/write/edit, `diffpi_modes_set`, `diffpi_modes_status`, `plan_verify`, Agent, get_subagent_result, steer_subagent, bash, ctx_execute, ctx_execute_file, watch_ci. **Children:** one same-session Orchestrator for `--bg`; thereafter one bounded low-thinking Worker per eligible task; one frontier/high reviewer only when the plan is draft.
+
+1. Parse `--mode no-commit|commit|push`; default is `no-commit`. Select the shared inline profile with `diffpi_modes_set({agent: "orchestrator"})` and verify `diffpi_modes_status` on the next turn. If switching or evidence fails, stop with the exact error. Git/project tasks and gates run through `bash` (or `ctx_execute` for large output); there are no `task`, `format`, `lint`, `test`, `ci`, `git`, or `push` tools.
+2. Select and reread the current live `PLAN.md` and all numbered briefs. Run `plan_verify` on that exact plan directory; if it reports issues, stop in its current state and repair through Planner before trying again. If `DRAFT`, invoke exactly one named `diffpi-plan-reviewer` per pass with `Agent(run_in_background:false)`; do not impose a short turn limit. Independently verify runtime attestation and require a **completed** child result with an explicit PASS and no BLOCKING findings. A `steered`, partial, stopped, missing, or failed result is NOT a pass. On findings, hand repairs to Planner, reread live files, rerun `plan_verify`, then invoke the same named reviewer profile in a fresh `Agent` call (not `resume`) within bounded attempts. Write `READY` and dispatch Workers ONLY after a current mechanical PASS and a completed attested reviewer PASS; otherwise leave `DRAFT` and stop with exact evidence. Do not launch a duplicate background child or recursively dispatch. If already `READY`, reread and verify current files as-is.
+3. The Orchestrator alone writes live plan checkboxes/status. Schedule a phase only after every prerequisite is complete. Derive a bounded Worker scope per task from that phase brief's sole fenced Files Affected tree and the task's steps; never invent separate per-task scope fields. Serialize when task-to-file ownership is uncertain or scopes overlap. Dispatch disjoint Workers concurrently only when prerequisites are complete and ownership is unambiguous. The Worker never edits plan files, commits, redispatches, asks questions, or falls back inline.
+4. Run the declared project format, lint, test, and CI gates through `bash`/`ctx_execute`. On Worker, gate, preflight, reviewer, or command failure, block; preserve the exact command/output, attempts, and affected role.
+5. In `no-commit`, continue only with verified gates. In `commit`, after all phase gates pass, make exactly one commit for that phase. In `push`, push that phase commit, obtain its exact SHA, and call `watch_ci` for that SHA; do not push or schedule the next phase until CI settles successfully.
+
+**Effects:** declared source/test changes plus serialized live-file status/checkboxes. Never edit plugin source or managed plan records. `--bg` launches one child only; it never redispatches.

package/skills/plan/references/workflows/help.md

@@ -1,10 +1,7 @@
 # `/plan help`
 
-## PLAN.md task
+**Owner/tier:** User, read-only. **Tools:** read/grep/find only. **Children:** none.
 
-Show the available plan commands and their concise purposes.
+Explain the verbs and ownership: `init` creates an `INCOMPLETE` live draft; `new` creates a complete plan; `update` edits one selected plan; `annotate` is optional human tuicr/direct-file review; `finalize` reviews and marks `READY`; `go` reviews drafts then orchestrates execution; `help` does nothing. Explain `--bg` launches exactly one named same-session Planner or Orchestrator child with the exact verb/target/cwd/commitMode, without redispatch or questions.
 
-## Brief
-
-1. List `init` (phase-less draft), `new` (research and author), `update` (apply review/instructions), `annotate` (tuicr review), `finalize` (validate and mark ready), `go` (start execution), and `help`.
-2. State that `--branch` records or filters metadata, `go` defaults to `--mode no-commit`, and background workflows do not ask questions.
+**Effects:** none. **Failure:** unknown or missing input returns this help; no files, reviewer, dispatch, or managed plan calls.

package/skills/plan/references/workflows/init.md

@@ -1,5 +1,10 @@
-# Init
+# `/plan init`
 
-1. Resolve the supplied short slug and optional branch, title, intent, issue ID, and URL. `--branch` records metadata; it does not switch branches. Call `plan_context` first and stop if the selected plan already exists.
-2. Call `plan_init` with `open: true` and `request: {kind: "user", text: <exact incoming request>}`. The tool creates one phase-less draft and its initial request-scoped revision snapshot, then opens `PLAN.md` in a supported adjacent editor tab. Do not perform additional content mutations for this request.
-3. Return the plan ID, clickable path, and actual launch outcome or fallback path. Explain that `annotate` stores a plan review, `update` applies review or further instructions, and `finalize` checks completeness before execution.
+**Owner/tier:** Planner, frontier/high. **Tools:** read/write/edit/find/grep, `diffpi_modes_set`, `diffpi_modes_status`. **Children:** none.
+
+1. Select the shared inline profile with `diffpi_modes_set({agent: "planner"})` (not `plan:planner`); on the next turn verify `diffpi_modes_status`. If either call or evidence is unavailable, stop with the exact error.
+2. Resolve the initiating nested Git root and unique flat `.diffpi/plan/<YYMMDD[-ticket]-short-slug>/` directory (one date-prefixed name, not `date/slug`). Inspect collisions before creating anything; on collision, stop without overwriting.
+3. Successively create the live directory, `PLAN.md`, and phase scaffolds with ordinary writes. Put `INCOMPLETE` in the visible `DRAFT` document; it is a marker, not a status enum.
+4. Read every created file back and report paths.
+
+**Effects:** only live plan files change. **Failure:** preserve partial files and report the exact path, command, and error; do not dispatch or ask questions in background. Foreground may ask one material goal question before writing.

package/skills/plan/references/workflows/new.md

@@ -1,7 +1,11 @@
-# New
+# `/plan new`
 
-1. Call `plan_context` for the supplied slug and branch. If a matching plan already exists, stop rather than silently overwriting it. If the goal is unspecified in foreground mode, use `ask_user_question` for the material scope decision; in background mode, state a blocker if no safe assumption exists.
-2. Research the relevant repository files, APIs, tests, and constraints before drafting. Follow [plan authoring quality](../design-quality.md): substantive Big Ideas bullets, illustrated API contracts, explicit before/after consequences, one stable PLAN.md task per implementation action, and a fully specified numbered brief per phase. Each brief must use numbered phase files, preserve exact phase/task IDs and order parity with PLAN.md, give ordered steps, exact file scopes, API/data contracts, algorithms/libraries, constraints, and acceptance criteria; inspect every rendered brief strictly for accuracy and completeness.
-3. Preserve the exact user request as a typed revision input. Build the **complete** candidate overview, ordered phases and task IDs, and matching briefs in memory. Call `plan_apply_revision` **once** with `mode: "create"`, the short slug, `request: {kind: "user", text: <exact incoming request>}`, a full overview and phase list, and one complete brief per phase; `create` writes revision 0 directly, so `/plan new` works without `plan_init`; do not create a phase-less shell first or open an editor.
-4. Validate the result strictly and inspect the generated brief paths. If any placeholders, missing task steps, mismatched IDs, or incomplete sections remain, report the failure rather than claiming readiness. A validation result is structural, not a check that source code already implements the plan.
-5. Report the plan ID and paths. Continue discussing changes in the same conversation; a later user request is a separate revision. Offer `annotate` for human review and `finalize` when ready, without making the user paste a command merely to continue this request.
+**Owner/tier:** Planner, frontier/high. **Tools:** read/write/edit/find/grep, `diffpi_modes_set`, `diffpi_modes_status`, `plan_verify`, Agent, get_subagent_result, steer_subagent. **Child:** exactly one independent `diffpi-plan-reviewer`, frontier/high, read/search-only.
+
+1. Select the shared inline profile with `diffpi_modes_set({agent: "planner"})` (not `plan:planner`) and verify `diffpi_modes_status` on the next turn; stop on unavailable switch or unverifiable evidence.
+2. Resolve the initiating nested Git root and a flat `.diffpi/plan/<YYMMDD[-ticket]-short-slug>/` directory (one date-prefixed directory, not `date/slug`). Check collisions and stop before writing an existing match. Research only after selection.
+3. Successively write `PLAN.md` and one numbered brief per phase. Document each phase's high-level constraints in `PLAN.md` (use `None` if empty) without copying implementation details there. Do not repeat or paraphrase those phase constraints in a brief; reference the phase ID instead. Give each brief a `## Files Affected` section immediately after `## Objective` and before `## Tasks`, containing exactly one fenced `text` action-labeled file tree rather than Markdown bullets, with free-form `## Implementation Constraints` after tasks; optional implementation subheadings are not mandatory. Preserve phase/task parity, dependencies, scopes, and acceptance criteria; read every file back.
+4. Run read-only `plan_verify` against the live directory and repair structural issues before invoking exactly one reviewer. Verify its attestation and review the complete current draft. Repair actionable findings, rerun `plan_verify`, then invoke the same named reviewer profile in a fresh `Agent` call (not `resume`) within bounded attempts.
+5. Leave the plan marked `DRAFT` after a successful review. Do not write `READY`; only `/plan finalize` or draft `/plan go` may do that.
+
+**Failure:** preserve visible files and exact evidence; block on collision, failed/unverifiable review, or exhausted repairs. Background never asks questions or redispatches.

package/skills/plan/references/workflows/update.md

@@ -1,7 +1,10 @@
-# Update
+# `/plan update`
 
-1. Call `plan_context` for the slug/branch; never guess among multiple candidates. Call `plan_review` once for the selected current revision before interpreting the request. A review of an older revision is stale; do not reapply it.
-2. Preserve the exact incoming request in `request.text` and select `request.kind` (`user`, `annotation`, or `blocker`) according to the trigger. When applying a plan review, read its full feedback; when unblocking execution, preserve the worker's blocker in the request. For annotation requests, include the exact LLM response/outcome in `request.response` and classify every comment as applied, answered, or unresolved with a concrete reason. Do not use vague “later” or “follow-up” deferrals unless the user explicitly requested that deferral. Research affected source files. Follow [plan authoring quality](../design-quality.md), including substantive Design sections and complete per-task implementation briefs. For both new and amended content, briefs must use numbered phase files, exact phase/task ID and order parity, ordered steps, exact file scopes, API/data contracts, algorithms/libraries, constraints, and acceptance criteria; strictly inspect every rendered brief for accuracy and completeness.
-3. Build the **entire resulting plan and numbered briefs in memory**, preserving completed task IDs, ownership, evidence, and dependencies. For a single authoring request, call `plan_apply_revision` with `mode: "amend"` exactly once, passing `plan`, `expectedPlanRevision`, `request`, the entire overview, ordered phases, and matching briefs. Do not mutate overview/phase/task content with separate tools, edit managed files by hand, or create a revision per comment.
-4. In foreground mode, ask only for missing decisions that materially affect scope; background work must not ask. Strictly validate the saved plan and briefs; stop with precise errors if they are incomplete. Do not treat structural validation as evidence that implementation already meets requirements.
-5. Report the one new revision and its snapshot path, what changed, and any remaining blocker. Further chat instructions form a future separate revision; `annotate` reviews the plan and `finalize` marks it ready.
+**Owner/tier:** Planner, frontier/high. **Tools:** read/write/edit/find/grep, `diffpi_modes_set`, `diffpi_modes_status`, `plan_verify`, Agent, get_subagent_result, steer_subagent. **Child:** exactly one independent `diffpi-plan-reviewer`, frontier/high, read/search-only.
+
+1. Select the shared inline profile with `diffpi_modes_set({agent: "planner"})` (not `plan:planner`) and verify `diffpi_modes_status` on the next turn; stop on unavailable switch or unverifiable evidence.
+2. Select exactly one plan by repository-root path. Read current `PLAN.md`, every numbered brief, and the request. Preserve intent, IDs, completed evidence, ownership, dependencies, and order.
+3. Research affected code, then successively edit/write authoritative live files and read each back. Keep the marker `DRAFT` (and any `INCOMPLETE` marker) until explicit finalize or go.
+4. Run read-only `plan_verify` against the current plan directory and repair structural issues. Invoke exactly one reviewer over the complete current plan. Verify actual model, thinking, and tools evidence. Repair actionable findings, rerun `plan_verify`, and reinvoke that named reviewer profile with a fresh `Agent` call (not `resume`) within bounded attempts.
+
+**Failure:** preserve visible edits and report exact evidence; block on ambiguity, unavailable role/reviewer evidence, failed review, or exhausted repair. No fallback reviewer, redispatch, or background questions.

package/skills/review/SKILL.md

@@ -1,15 +1,15 @@
 ---
 name: review
-description: Create, edit, review, address, publish, complete, and merge GitHub/GitLab or local tuicr reviews. Use for /skill:review, /review, or natural-language review requests.
-allowed-tools: read ask_user_question Agent get_subagent_result steer_subagent review_context review_status review_new review_open review_edit review_diff review_gates review_submit review_add_comment review_comments review_respond review_publish review_complete review_merge review_launch_ui diffpi_template
+description: Create, edit, review, address, publish, complete, and merge GitHub/GitLab or local tuicr reviews.
+allowed-tools: read ask_user_question Agent get_subagent_result steer_subagent bash review_context review_status review_new review_open review_edit review_diff review_gates review_submit review_add_comment review_comments review_respond review_publish review_complete review_merge review_launch_ui diffpi_template
 ---
 
 # Review
 
-This skill owns the workflow. `/review` only forwards raw arguments to `/skill:review`; never rely on command-side flag parsing or mode activation. Parse the first non-flag argument as the verb and preserve remaining arguments and their order. Normalize `create`, `draft` → `new`; `launch` → `auto`; `ready` → `publish`; `close` → `complete`; `land` → `merge`. `open` and `status` are first-class lifecycle workflows. Empty/unknown verb shows [help](references/workflows/help.md).
+Parse the first non-flag argument as the verb; preserve remaining arguments. Aliases: `create`/`draft` → `new`, `launch` → `auto`, `ready` → `publish`, `close` → `complete`, `land` → `merge`. Unknown or empty verbs show [help](references/workflows/help.md). `--local` selects tuicr working-tree state and must be preserved; otherwise use the selected forge. `--bg` removes itself and launches exactly one named same-session background Orchestrator with verb, arguments, cwd, exact target/backend, and `background: true`; it must not redispatch or ask questions. Foreground execution stays in this turn and never changes inline mode.
 
-`--local` selects the working-tree tuicr backend and **must be preserved** for the selected workflow; without it, use the forge. `--bg` is an execution flag: remove it from the child request and launch exactly one named background Orchestrator through `Agent`, passing verb, arguments, cwd, and an explicit `background: true` instruction. The child executes the workflow once without redispatch or interactive questions; the current foreground role remains unchanged. Without `--bg`, execute directly in this turn. Do not change inline modes or emit a command for the user to paste. Do not launch a multi-agent workflow unless the user explicitly opts into one.
+Read the selected reference before acting. Every target-bearing workflow calls `review_context` FIRST, then uses the same target, backend, `local` value, and cwd for every call; help is informational and may run without a target or repository. Tools own target selection, lifecycle, templates, comments, replies, publication, and forge calls. Do not reimplement them or invent tools. Report failed and skipped gates as such. Keep remote findings/comments pending until publish; local work remains tuicr state until promotion or completion. Do not publish, complete, merge, or resolve threads from auto/address.
 
-Read [the selected reference](references/workflows/) before acting. Every operational workflow calls `review_context` first with the same target and `local` setting. Use `ask_user_question` only for material decisions not derivable from the request; never ask as plain chat text. `auto` and `address` require reviewer judgment and thread classification; if a background Orchestrator is running, delegate that bounded judgment to a Reviewer via `Agent`, then collect the result. Delegate non-overlapping implementation only where useful. Lifecycle verbs retain the coordinator role. Tools own target selection, templates, comment staging, replies, publication, and forge calls; do not reimplement them with shell commands.
+The foreground high-tier Reviewer owns only auto judgment and address classification/replies; lifecycle coordination belongs to the coordinator, which owns new/open/status/edit/publish/complete/merge and does not delegate these to a Reviewer child. In background mode the Orchestrator retains lifecycle coordination and delegates exactly one bounded high-tier Reviewer judgment child for auto/address only; the child does not edit source or recurse. `address` lets the Reviewer classify threads and delegate bounded, non-overlapping source edits to low-thinking Workers. Workers never commit, reply, publish, complete, merge, or resolve. Remote code changes are committed by the coordinator through the upstream `/git commit --no-push` workflow after checks and before replies (use `--atomic` for separate logical commits); local changes remain uncommitted. Address replies always use `review_respond(resolve:false)`; local thread resolution remains user-owned.
 
-References: [auto](references/workflows/auto.md), [new](references/workflows/new.md), [open](references/workflows/open.md), [status](references/workflows/status.md), [edit](references/workflows/edit.md), [address](references/workflows/address.md), [publish](references/workflows/publish.md), [complete](references/workflows/complete.md), [merge](references/workflows/merge.md), [help](references/workflows/help.md). Keep publication separate from completion and merge; `review_merge` remains GitHub-only.
+References: [auto](references/workflows/auto.md), [new](references/workflows/new.md), [open](references/workflows/open.md), [status](references/workflows/status.md), [edit](references/workflows/edit.md), [address](references/workflows/address.md), [publish](references/workflows/publish.md), [complete](references/workflows/complete.md), [merge](references/workflows/merge.md), [help](references/workflows/help.md). `review_merge` is GitHub-only; approval by the current user is not required.

package/skills/review/references/workflows/address.md

@@ -1,11 +1,10 @@
 # address
 
-1. Parse an optional PR/MR id or URL and `--local`. The skill owns `--bg` dispatch before this reference is followed; a background child executes these steps directly and must not redispatch.
-2. Run this workflow as the reviewer coordinator. Call `review_context` first with the same target and `local: true` when `--local` is present, otherwise `local: false`.
-3. Call `review_comments` with the same target and backend. With `--local`, it synchronizes every comment in the selected tuicr session to `.diffpi/review/<session-slug>.md`. Existing replies and statuses remain; source comments removed by the user become resolved ledger entries.
-4. Classify every thread, group justified code changes into bounded non-overlapping tasks, and delegate those tasks to lightweight worker agents. Keep questions, outcome decisions, integration, and response text in the reviewer coordinator. With `--local`, workers modify the current working tree without committing. Without `--local`, apply a fix only when the comment requests a change.
-5. Apply every relevant requested change in this workflow. Do not label a relevant request deferred, later, or follow-up unless the user explicitly requested deferral. Use unresolved only for a concrete external blocker or material user decision, and state the attempted fixes and evidence. Respond to every thread with an explicit outcome and verification evidence. Answer questions and leave them open. For substantive requests, state what changed and whether it is resolved, but leave every thread open for the user to resolve. Do not resolve remote threads or delete local source comments in this workflow, including for trivial requests.
-6. When a remote address flow changes code, invoke the upstream `/git commit --no-push` workflow after checks pass and before drafting responses. Use `--atomic` when the fixes form separate logical commits.
-7. Call `review_respond` for each thread with `resolve: false`. With `--local`, every response is posted to tuicr and recorded in the session ledger. Without `--local`, replies post to the forge immediately. The user owns thread resolution.
-8. With `--local`, call `review_launch_ui` with `local: true` after replies are recorded so the user can inspect the working-tree review in tuicr.
-9. Report fixed, committed, answered, addressed, unresolved, and skipped counts. Resolved must always be zero in this workflow. Do not publish, complete, or merge.
+**Owner/tier:** foreground high-tier Reviewer-coordinator; background Orchestrator coordinates and delegates bounded low-thinking Workers. Reviewer classifies threads; Workers may edit source only.
+
+1. Call `review_context` first with exact target/backend/local, then `review_comments` with the same values.
+2. Reviewer classifies every thread and groups only bounded, non-overlapping requested source changes. Delegate those edits to Workers. Workers never commit, reply, publish, complete, merge, resolve, or recurse. Questions remain open. Report unmatched threads and blockers.
+3. Run `review_gates` after edits and report failures/skips. For remote code changes, coordinator invokes upstream `/git commit --no-push` after checks and before replies (`--atomic` for separate logical commits). Local changes stay uncommitted.
+4. Coordinator calls `review_respond` for every outcome with `resolve:false`; never resolve or delete threads. With local state, optionally call `review_launch_ui` after replies. Do not publish, complete, or merge.
+
+Report fixed, committed, answered, unresolved, skipped, and failed counts; resolved is always zero.

package/skills/review/references/workflows/auto.md

@@ -1,18 +1,9 @@
 # auto
 
-1. Parse an optional PR/MR id or URL and `--local`. The skill owns `--bg` dispatch before this reference is followed; a background child executes the remaining steps directly and must not redispatch. `launch` aliases this workflow.
-2. Call `review_context` first with the same target and `local: true` when `--local` is present, otherwise `local: false`.
-3. Call `review_new` with the same target and backend selection to create the local tuicr review or remote draft PR/MR and open its tuicr UI. A remote branch must be clean and pushed. If the review already exists, use `review_edit` with the same backend instead.
-4. Before reviewing, run `review_gates` so the project's discovered format-check and lint tasks run first, followed by its other gates. Preserve and report failures; do not substitute visual inspection for failed or skipped checks.
-5. Run review judgment as the reviewer agent. Inline, the reviewer performs the workflow tool calls directly. In background execution, the orchestrator delegates judgment to the reviewer and retains lifecycle calls. The reviewer fetches the diff with `review_diff` and may launch parallel lightweight subagents for independent areas when useful.
-6. Review the change for:
-   - whether it accomplishes the stated intent;
-   - whether the technical approach is the best practical way to accomplish that intent;
-   - correctness, including failure paths and edge cases;
-   - code quality, readability, and maintainability;
-   - minimality and conciseness, including unnecessary agent-generated changes;
-   - documentation accuracy and completeness; and
-   - reviewer coordination, including keeping lifecycle ownership clear and avoiding duplicate or conflicting findings.
-     Use parallel lightweight workers for independent review areas when useful, then reconcile their results before submission.
-7. Produce only grounded findings, then call `review_submit` with the same target and backend (`local: true` for `--local`, otherwise `local: false`). Remote findings remain pending for `publish` or `complete`.
-8. Report the artifact or pending-review state, finding count, gate results, backend, and any launch instruction. Do not complete or merge the review.
+**Owner/tier:** foreground high-tier Reviewer-coordinator; background Orchestrator coordinates and delegates one high-tier Reviewer child. No source edits.
+
+1. Parse target and `--local` (and let the skill handle `--bg` before this file). Call `review_context` first, then keep exact target/backend/local/cwd.
+2. Call `review_new`; if the review already exists, call `review_edit`. Call `review_gates`, then `review_diff`.
+3. Reviewer judges intent, correctness, edge cases, quality, minimality, docs, and duplicate findings. Report every gate failure or skip. Submit only grounded findings with `review_submit`; remote findings remain pending. Do not call publish, complete, merge, or resolve threads.
+
+On missing target/backend, unsupported forge, failed creation, or failed gates, preserve state, report exact evidence, and stop or continue only with clearly reported skipped checks. Return artifact, backend, gate results, and finding count.

package/skills/review/references/workflows/complete.md

@@ -1,7 +1,7 @@
 # complete
 
-1. Parse an optional PR/MR id or URL, `--local`, and exactly one remote action: `--approve`, `--reject`, or `--abandon`. The skill-owned `close` alias follows this workflow. Skill-owned `--bg` dispatch has already occurred; a background child must not redispatch or ask questions. If a remote action is missing in foreground mode, ask the user with `header: "Action"`; all question headers must be 16 characters or fewer. In background mode, stop with a blocker instead of guessing.
-2. Call `review_context` first with the same target and `local: true` when `--local` is present, otherwise `local: false`.
-3. With `--local`, call `review_complete` with `local: true`. It archives the reply overlay to `.diffpi/reviews/<session-slug>.md`, then deletes the exact persisted tuicr session. This is destructive and prevents its comments from appearing in future tuicr sessions.
-4. Without `--local`, map `--approve`, `--reject`, or `--abandon` to the `review_complete` action `approve`, `reject`, or `abandon`. The tool applies the remote lifecycle action but does not merge.
-5. Report the archive path or remote result. Do not call `review_merge`.
+**Owner/tier:** lifecycle coordinator; no Reviewer or Worker.
+
+1. Parse target, `--local`, or exactly one remote action: approve, reject, abandon. Call `review_context` first with the same values. If a remote action is missing, ask with `ask_user_question`; background mode must stop rather than guess.
+2. Call `review_complete` with local true for local archive or the mapped remote action. Local completion archives the overlay and removes the matching tuicr session; remote completion does not merge.
+3. Report archive/result and any failure. Never publish or call `review_merge`.

package/skills/review/references/workflows/edit.md

@@ -1,7 +1,5 @@
 # edit
 
-1. Parse an optional PR/MR number, URL, or branch target and `--local`. Skill-owned background dispatch has already occurred; a background child follows these steps without redispatch.
-2. Call `review_context` first with the same target and `local: true` when `--local` is present, otherwise `local: false`.
-3. Call `review_edit` with the same target and backend. With `--local`, it opens an existing local tuicr session. Without `--local`, it opens an existing PR/MR in tuicr, including a non-draft PR/MR for continued work on its comments.
-4. If no matching local session or remote PR/MR exists, report the error and direct the user to `new`. Do not create a review, generate findings, publish, complete, or merge.
-5. Report whether tuicr opened in a mux, prepared a Zed task, or returned a command.
+**Owner/tier:** lifecycle coordinator; no findings judgment.
+
+Call `review_context` first, then `review_edit` with the same target/backend/local. It opens an existing local session or remote PR/MR in tuicr without generating findings. Report missing sessions, unsupported targets, and launch failures. Do not create, publish, complete, merge, or resolve.

package/skills/review/references/workflows/help.md

@@ -1,36 +1,15 @@
 # help
 
-Print the following help text:
-
 ```text
-Workflows for PRs and local review. Use:
-
-Create a review and generate findings:
-  /review auto [pr-or-branch] [--local] [--bg]
-
-Create a local review or remote draft PR/MR:
-  /review new [title] [--intent text] [--base branch] [--local] [--bg]
-
-Open an existing remote PR/MR in the system browser (never creates one):
-  /review open [pr-number|pr-url|branch] [--local]
-
-Show review and worktree lifecycle status:
-  /review status [pr-number|pr-url|branch] [--local]
-
-Open an existing review in tuicr without generating findings:
-  /review edit [pr-number|pr-url|branch] [--local] [--bg]
-
-Address review comments:
-  /review address [pr-number|pr-url|branch] [--local] [--bg]
-
-Publish comments and a review status:
-  /review publish [pr-number|pr-url|branch] [--local] [--comment|--approve|--request-changes|--close] [--bg]
-
-Complete a review without merging:
-  /review complete [pr-number|pr-url|branch] [--local|--approve|--reject|--abandon] [--bg]
-
-Merge an approved remote review:
-  /review merge [pr-number|pr-url|branch] [--bg]
+/review auto [target] [--local] [--bg]
+/review new [title] [--intent text] [--base branch] [--local] [--bg]
+/review open [target] [--local]
+/review status [target] [--local]
+/review edit [target] [--local] [--bg]
+/review address [target] [--local] [--bg]
+/review publish [target] [--local] [--comment|--approve|--request-changes|--close] [--bg]
+/review complete [target] [--local|--approve|--reject|--abandon] [--bg]
+/review merge [target] [--bg]
 ```
 
-`--local` selects the working-tree tuicr backend. Otherwise, a target is a PR/MR number, URL, or branch; no target means the current branch. `--bg` launches a tracked background Orchestrator and leaves the current chat mode unchanged. `new` creates a review. `open` opens an existing remote URL in the system browser, or directs to `new`; with `--local` it creates/opens the local working-tree review. `status` reports local and remote state without requiring a forge or tuicr binary. `edit` only opens an existing local session or remote PR/MR in tuicr. `auto` creates a review, then delegates findings to the reviewer agent. `create` and `draft` alias `new`; `launch` aliases `auto`; `close` aliases `complete`. `publish` publishes remote draft PR/MR review comments and status or promotes local comments. `complete` makes a lifecycle decision without merging, or archives the local overlay and deletes its tuicr session.
+Every target-bearing workflow calls `review_context` first; help is informational and may run without a target or repository. `--local` selects working-tree tuicr state and is preserved; otherwise use the forge. `--bg` launches one named same-session Orchestrator child without redispatch or mode changes. `auto` reviews and stages grounded findings; `new` creates a draft; `open` opens an existing target; `status` is read-only; `edit` opens without findings; `address` fixes and replies without resolving; `publish` publishes/promotes pending work; `complete` approves/rejects/abandons or archives local state without merging; `merge` is GitHub-only and requires clean settled readiness. Aliases: create/draft=new, launch=auto, ready=publish, close=complete, land=merge. Unknown verbs show this help.

package/skills/review/references/workflows/merge.md

@@ -1,6 +1,5 @@
 # merge
 
-1. Parse an optional PR number, URL, or branch. This workflow is remote-only; reject `--local`. The skill has already handled `--bg`; a background child must not redispatch. Call `review_context` first with the target and `local: false`. Do not query the forge through MCP or duplicate merge-readiness checks: `review_merge` uses the GitHub CLI to confirm the PR is open, non-draft, clean, and its checks are settled before merging. Do not require approval from the current user; authors cannot approve their own PRs. GitHub branch protection remains authoritative.
-2. If a conventional squash subject is required and the subject is unclear, use `ask_user_question`.
-3. Call `review_merge` with the chosen subject. Treat its CLI-backed readiness result as authoritative.
-4. Report the merge result.
+**Owner/tier:** lifecycle coordinator; remote GitHub-only, no Reviewer or Worker.
+
+Reject `--local`. Call `review_context` first with `local:false`, then `review_merge`; the tool checks open, non-draft, clean PR and settled checks and uses branch protection as authoritative. Approval by the current user is not required. Ask only when a conventional squash subject is materially unclear. Report merge or readiness failure. Merge never publishes or completes review state.