@difflab/pi 0.7.0 → 0.7.1-rc.202609290811.4ccd593

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-rc.202609290811.4ccd593",
   "description": "Tools and skills for the pi coding agent",
   "repository": {
     "type": "git",
@@ -59,7 +59,7 @@
     "@juicesharp/rpiv-ask-user-question": "^2.10.1",
     "commander": "^14.0.0",
     "mdast-builder": "1.1.1",
-    "pi-mcp-adapter": "^2.33.0",
+    "pi-mcp-adapter": "^2.38.0",
     "remark-stringify": "11.0.0",
     "unified": "11.0.5",
     "zod": "^4.6.5"

package/skills/diffpi-setup/SKILL.md

@@ -47,4 +47,4 @@ Map `None`, `Linear`, and `Jira` to `none`, `linear`, and `jira`. Infer the revi
 
 When the user is using Zed, ask separately whether to bind `cmd-alt-r` to the `diffpi: tuicr review` task. Only pass `bindZedKey: true` when the user opts in; otherwise pass `false`.
 
-Setup installs Diffpi's bundled agent Markdown into Pi's standard global agent directory. Explain that each default can run through the subagent plugin or as the current inline prompt. `/skill:mode` opens the structured picker. It also accepts `--include-skills`, one agent id, a qualified `skill:agent` id, or `clear`.
+Setup installs Diffpi's bundled agent Markdown into Pi's standard global agent directory. The agents run through the subagent plugin; no inline profile selection is required for plan or review workflows.

package/skills/plan/SKILL.md

@@ -1,17 +1,21 @@
 ---
 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.
 ---
 
 # 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.
+Route the verb and remaining request to its workflow. Fuzzy-match recognizable natural language; treat argument shapes as hints, not rigid gates.
 
-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.
+| Input                                        | Workflow                                     |
+| -------------------------------------------- | -------------------------------------------- |
+| `init <slug> [--branch <branch>]`            | [init](references/workflows/init.md)         |
+| `new <slug> <request>`                       | [new](references/workflows/new.md)           |
+| `update <slug> <request>`                    | [update](references/workflows/update.md)     |
+| `annotate <plan-path>`                       | [annotate](references/workflows/annotate.md) |
+| `validate <slug>`                            | [validate](references/workflows/validate.md) |
+| `finalize <slug>`                            | [finalize](references/workflows/finalize.md) |
+| `go <slug> [--mode no-commit\|commit\|push]` | [go](references/workflows/go.md)             |
+| `help`, missing or unrecognizable request    | [help](references/workflows/help.md)         |
 
-`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.
-
-`--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.
-
-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).
+Follow the selected workflow. For `init`, `new`, `update`, DRAFT `validate`, `finalize`, or `go` when no native subagents are available, follow [the explicit inline exception](references/workflows/inline-fallback.md) only after the caller obtains confirmation; never silently fall back.

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. Every Verify command must be executable when that task finishes: do not require a test file, build artifact, dependency, or command created only by a later task. Use an inline smoke check or move the test creation earlier when needed.
+- 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, perform observed read-only structural verification, then invoke the independent `diffpi-plan-reviewer` exactly once per authoring cycle over the complete snapshot. Require the actual completed independent `diffpi-plan-reviewer` result, record its verdict and findings, and compare plan hashes and Git state around it; a reviewer mutation invalidates the round. The reviewer is instructed not to mutate but inherits ambient capabilities, so read-only behavior is a policy, not a sandbox.
 
-## Consequences
+The Planner documents each actionable finding and its disposition, repairs it, rereads changed files, and reruns only observed read-only structural verification. Do not automatically rerun the reviewer. Keep the plan DRAFT until explicit finalize/go checks completed review evidence and dispositions. A BLOCKING verdict remains BLOCKING even when repaired; a passing review does not prove source implementation. `annotate` is optional human review, not a replacement for the automated round.
 
-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,13 @@
 # `/plan annotate`
 
-## PLAN.md task
+## Parse arguments
 
-Review the selected plan in tuicr and save one immutable review.
+Syntax: `annotate <plan-path>` (no flags required; use an explicit target if supplied).
 
-## Brief
+1. Match `annotate` or clear intent to inspect a plan with a human. Resolve one plan path from explicit input before inferred request/repository context, then a safe default if unique. Do not require a positional path when a single target is evident. Ask via `ask_user_question` only for material ambiguity; route truly insufficient intent to full [help](help.md).
 
-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.
+## Steps
+
+1. Open the selected PLAN.md and numbered briefs in `tuicr --file` or a direct-file human review in the foreground. Do not launch an automatic Plan Reviewer.
+2. Tie human comments to current plan file paths. Leave plan files, status and checkboxes unchanged. Direct requested edits to a separate explicit `/plan update`, or readiness to `/plan finalize`.
+3. Report exact file or review UI failures; do not turn annotation into an automated second reviewer round.

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

@@ -1,7 +1,14 @@
-# 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.
+## Parse arguments
+
+Syntax: `finalize <slug>` (optional `--plan <plan-path>` or `--target <plan-path>`).
+
+1. Infer readiness intent and unique target from explicit args/flags first, then natural language and repository context. Do not require an inferable slug. Ask `ask_user_question` in the caller for material ambiguity; send insufficient intent to [help](help.md).
+
+## Steps
+
+If DRAFT and no native subagents are available, ask for explicit confirmation in the caller and follow [the inline exception](inline-fallback.md); a passing inline structural and review/disposition validation under that recorded exception permits READY. Otherwise stop with a blocker.
+
+1. Resolve the initiating Git root, absolute PLAN.md and numbered briefs. If DRAFT, invoke [validate](validate.md) through its **one** separate frontier/high `diffpi-planner` background child with the resolved path, filling the self-contained fenced `text` prompt in validate.md before launch and collecting the completed result. Do not launch a second child or another reviewer. If validation is incomplete or blocked, leave DRAFT and report the blocker.
+2. The **calling agent** (not the child) checks the completed validation result and durable evidence against the current files, then makes the short DRAFT → READY transition and reads it back. If the plan is already READY, read it back without revalidation. Do not execute tasks. Report status and evidence or exact blocker.

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

@@ -1,8 +1,29 @@
-# 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.
+# `/plan go`
+
+## Parse arguments
+
+Syntax: `go <slug> [--mode no-commit|commit|push]` (optional `--plan <plan-path>` or `--target <plan-path>`).
+
+1. Infer execution intent, unique target and mode from explicit args/flags first, then natural language and repository context. Default mode to `no-commit`; never infer commit or push authorization from silence. Do not require an inferable slug. Ask `ask_user_question` in the caller for material ambiguity; send insufficient intent to [help](help.md).
+
+## Steps
+
+If no native subagents are available, ask for explicit confirmation in the caller and follow [the inline exception](inline-fallback.md) for DRAFT readiness and/or READY execution; otherwise stop with a blocker. Never silently execute inline.
+
+1. Resolve the initiating Git root, absolute PLAN.md and all numbered briefs. If DRAFT, call [validate](validate.md) through its separate frontier/high planner background child with the resolved paths and collect actual completion; on failed/incomplete validation leave DRAFT and stop. On PASS the calling agent checks current evidence, transitions DRAFT → READY and reads back. If already READY, **skip validate**, reviewer and structural revalidation; read status and proceed. Do not send DRAFT to the orchestrator.
+2. Fill every placeholder with actual request, paths and chosen mode before launch (no literal placeholders). Launch a medium `diffpi-orchestrator` background agent with ambient capabilities and this prompt:
+
+```text
+Execute this READY live plan under the user-approved policy. Do not run a plan reviewer or revalidate READY for readiness.
+- Exact request: {exact-request}
+- Initiating Git root: {repo-root}
+- Absolute READY PLAN.md path: {plan-path}
+- Absolute numbered brief paths: {brief-paths}
+- Mode: {mode} (no-commit|commit|push)
+- Read PLAN.md and every brief; require READY. Own execution status and checkboxes, schedule phases after prerequisites and persist actual results before more work.
+- Derive bounded task scopes from steps and each brief's sole action-labeled fenced `text` Files Affected tree; serialize uncertain/overlapping scopes. Delegate disjoint tasks to lightweight `diffpi-worker` background agents with concrete scopes, acceptance checks and ambient capabilities. Collect completed results, escalate blocked work and route bounded fixes; reload plan state before rescheduling. Workers edit only assigned source/test files, never plan lifecycle or commits.
+- Run project format, lint and tests after phase work; preserve failures, warnings and attempts; block on failed gates. In no-commit, do not commit or push. In commit, create exactly one phase commit after gates, do not push. In push, commit and push, then wait for settled CI on the exact observed SHA before the next phase. Block on unavailable exact-SHA monitoring, timeout, partial or failed CI. Local gates cannot be replaced by CI.
+- Return actual completed results or precise blockers, without background questions.
+```
+
+3. Report the job ID and actual completed result or precise background-capability blocker.

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

@@ -1,10 +1,24 @@
 # `/plan help`
 
-## PLAN.md task
+## Parse arguments
 
-Show the available plan commands and their concise purposes.
+Syntax: `help` (no flags or positional arguments required).
 
-## Brief
+1. Match `help`, a missing/unrecognizable verb, or genuinely insufficient intent. Fuzzy-match recognizable natural-language plan requests to their verb before showing help. Do not treat an inferable missing positional argument as insufficient; give explicit arguments/flags precedence over request/repository inference, then safe defaults.
 
-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.
+## Steps
+
+1. Show the complete usage below for explicit help or truly unrecognizable/insufficient intent. Identify any invalid argument in the error context without losing the original request.
+
+```text
+/plan init <slug> [--branch <branch>]
+/plan new <slug> <request>
+/plan update <slug> <request>
+/plan annotate <plan-path>
+/plan validate <slug> [--plan <plan-path>]
+/plan finalize <slug>
+/plan go <slug> [--mode no-commit|commit|push]
+/plan help
+```
+
+2. Describe these argument shapes as guidance rather than rigid gates; send a recognizable request to its verb for inference. Make no plan changes.

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

@@ -1,5 +1,27 @@
-# 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.
+## Parse arguments
+
+Syntax: `init <slug> [--branch <branch>]` (optional target/issue inferred from request).
+
+1. Infer scaffold intent, slug, branch and issue from explicit args/flags first, then natural language and the initiating Git root, then safe defaults. A positional slug is not required when inferable. Ask `ask_user_question` in the caller only for material ambiguity; send insufficient intent to [help](help.md).
+
+## Steps
+
+If no native subagents are available, ask for explicit confirmation in the caller and follow [the inline exception](inline-fallback.md); otherwise stop with a blocker. Do not silently scaffold inline.
+
+1. Resolve the unique initiating Git root and absolute PLAN.md target. Replace every placeholder below with actual values (use `none` for absent issue/branch); never pass literal placeholders. Launch a low `diffpi-worker` background agent with this bounded prompt and ambient capabilities:
+
+```text
+Scaffold an incomplete live plan, and do nothing else.
+- Exact request: {exact-request}
+- Initiating Git root: {repo-root}
+- Absolute PLAN.md target: {plan-path}
+- Branch and issue: {branch-and-issue}
+- Check collisions before writing. Use one flat `.diffpi/plan/<YYMMDD[-ticket]-short-slug>/` directory, never `date/slug`.
+- Create PLAN.md and phase scaffolds with ordinary writes, DRAFT and a visible INCOMPLETE marker (not a status). This init-only exception permits plan-file creation, but not status transitions beyond the initial DRAFT scaffold, source edits, execution or review.
+- Reread created files. Do not validate or launch a reviewer for the incomplete scaffold.
+- Return created paths or the exact failed operation/path/error; return unresolved decisions as blockers without interactive questions.
+```
+
+2. Report the job ID and actual completed result or precise background-capability blocker. Do not scaffold in the caller.

package/skills/plan/references/workflows/inline-fallback.md

@@ -0,0 +1,9 @@
+# Explicit inline exception when no native subagents exist
+
+Apply this policy only to `init`, `new`, `update`, DRAFT `validate`, `finalize`, or `go` when **no native subagent mechanism is available** to the initiating conversation. Try any available attached subagent dispatch/completion transport before treating native subagents as unavailable; a missing named tool alone is not proof. A failed reviewer, gate, implementation, structural check, CI check, or unavailable particular model is **not** an excuse to switch inline. Do not silently fall back after a child is queued, stopped, incomplete, or fails; return its actual blocker.
+
+Before substantive inline work, the **calling agent** must ask `ask_user_question` and receive explicit confirmation for the inline exception. State that this is a last resort with reduced isolation/model-tier guarantees and that review in the same thread is **not independent**. Offer a choice to proceed inline or stop; a declined, abandoned, or unavailable questionnaire (including in a background child or noninteractive eval) means **stop and report the blocker to the initiating thread**. Do not infer consent from the request, a prior unrelated approval, or silence. Record the confirmation and its scope with the authoring-cycle evidence; one confirmation can cover the named operation and its chained validation/readiness/execution steps, but a later user-initiated update requires confirmation again. Noninteractive evals still require an actual completed child; they cannot opt into inline fallback.
+
+After confirmation, perform the **same selected workflow** in the caller, with the same paths, collision checks, statuses, role boundaries, snapshots, Git evidence, findings, repairs, one-round budget, gates, CI and commit/push authorization. For `init`, create only an incomplete DRAFT scaffold. For `new` and `update`, make requested draft edits, then validate; `update` must preserve completed work and earlier evidence. For DRAFT `validate`, first run a working read-only structural check and repair structural defects as in the normal workflow. Capture every plan path/hash and Git HEAD, porcelain status, diff and untracked inventory before the review and again immediately afterward. Perform **one distinct read-only inline Plan Reviewer checklist pass** on the whole draft per authoring cycle, checking structure and parity, phase prerequisites/constraints, tree placement, ordered steps and temporally runnable Verify commands, intent/design consistency, risks and Worker executability. Record provenance as **INLINE reviewer (same thread, not independent)**, the actual verdict and line-specific BLOCKING/CONSIDER/NOTE findings (or explicit empty list), reviewed and post-review snapshots, Git evidence, and concrete dispositions in References or a linked durable artifact. Never fabricate a child ID, completed subagent, independent verdict or independent PASS. Reuse a valid completed round from the cycle rather than automatically reviewing a second time. Reviewer pass is read-only: if the pass mutates files or evidence changes unexplained, invalidate it. Repair actionable findings outside that pass, preserve an original BLOCKING verdict, reread and rerun **only** the structural check; do not call repaired content reviewer-approved. Failed structural checks, unresolved BLOCKING findings or unexplained changes block readiness.
+
+For `finalize` or DRAFT `go`, after **passing inline structural verification and inline review/disposition validation under the recorded approved exception**, the caller may mark DRAFT → READY, reread it, and continue the selected workflow. This exception does not waive any failed check. Already-READY `go` still skips readiness validation. If no native subagents remain for execution, the confirmed caller performs Orchestrator and bounded Worker steps inline with serialized uncertain/overlapping scopes and the same phase gates, no-commit/commit/push policy and exact-SHA CI requirements. Do not claim inline work was delegated or independently reviewed. If the user declines or cannot be asked, return the blocker rather than modifying the plan or executing work.

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

@@ -1,7 +1,26 @@
-# 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.
+## Parse arguments
+
+Syntax: `new <slug> <request>` (optional `--target <plan-path>`, `--issue <id>`, `--issue-url <url>`).
+
+1. Infer creation intent, slug, target, branch, issue and requested outcome from explicit args/flags first, then natural language and repository context, then safe defaults. Do not require inferable positionals. Ask `ask_user_question` in the caller for material ambiguity; send insufficient intent to [help](help.md).
+
+## Steps
+
+If no native subagents are available, ask for explicit confirmation in the caller and follow [the inline exception](inline-fallback.md), including chained validation; otherwise stop with a blocker. Never silently draft inline.
+
+1. Resolve the initiating Git root and unique absolute PLAN.md target. Fill every placeholder with actual values before launch (use `none` for absent context). Launch a frontier/high `diffpi-planner` background agent with ambient capabilities:
+
+```text
+Draft a complete live plan; do not dispatch a reviewer or mark READY.
+- Exact request: {exact-request}
+- Initiating Git root: {repo-root}
+- Absolute PLAN.md target, branch and issue: {plan-path-and-context}
+- Reject collisions; use a flat `.diffpi/plan/<YYMMDD[-ticket]-short-slug>/` directory.
+- Inspect the repository and resolve design questions. Write PLAN.md with intent, requirements, design, references, stable phase/task IDs, phase prerequisites and constraints (or None), and flat task checkboxes.
+- Write every numbered brief. Put exactly one action-labeled fenced `text` Files Affected tree immediately after Objective. Include ordered task steps, Verify commands runnable before later tasks, acceptance criteria and free-form Implementation Constraints.
+- Reread all files. Leave DRAFT. Return paths and completed result or exact blocker; do not ask background questions.
+```
+
+2. Collect the completed draft result. On success run [validate](validate.md) once in this authoring cycle, using the resolved plan path; its own child owns the independent review round. Leave DRAFT even on validation PASS. Report actual result and blockers, not just the job ID.

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

@@ -1,7 +1,26 @@
-# 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.
+## Parse arguments
+
+Syntax: `update <slug> <request>` (optional `--plan <plan-path>` or `--target <plan-path>`).
+
+1. Infer revision intent, unique target and requested edits from explicit args/flags first, then natural language and repository context. Do not require inferable positionals. Ask `ask_user_question` in the caller for material ambiguity; send insufficient intent to [help](help.md).
+
+## Steps
+
+If no native subagents are available, ask for explicit confirmation in the caller **before edits** and follow [the inline exception](inline-fallback.md), including chained validation; otherwise stop with a blocker. Never silently revise inline.
+
+1. Resolve the initiating Git root, absolute PLAN.md and numbered brief paths. Fill all placeholders with actual values before launch. Launch `diffpi-planner` on its configured frontier model with explicit **low** thinking and `inherit_context: true` (fork the parent conversation at launch), in the background with ambient capabilities:
+
+```text
+Revise only the requested unfinished plan work in a new user-initiated authoring cycle. Do not validate or dispatch a reviewer.
+- Exact requested edits: {exact-request}
+- Initiating Git root: {repo-root}
+- Absolute PLAN.md path: {plan-path}
+- Absolute numbered brief paths: {brief-paths}
+- Read PLAN.md and all briefs. Preserve stable IDs, dependencies, completed work, prior reviewed snapshots, verdicts, dispositions and execution history. Amend only draft/pending/blocked work; preserve INCOMPLETE if still incomplete.
+- Research affected code and make only requested changes. Keep phase prerequisites/constraints (or None), flat task checkboxes and exactly one action-labeled fenced `text` Files Affected tree immediately after Objective in each brief. Keep ordered steps, acceptance criteria, temporally runnable Verify commands and free-form Implementation Constraints.
+- Reread files, leave DRAFT, return changed paths and exact result or blocker. Do not ask background questions.
+```
+
+2. Collect the completed edit result. On success the caller launches the separate [validate](validate.md) child for this new authoring cycle (one independent review round maximum) and reports its result; leave DRAFT. Do not put review inside the edit child or discard earlier evidence.

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

@@ -0,0 +1,31 @@
+# `/plan validate`
+
+## Parse arguments
+
+Syntax: `validate <slug>` (optional `--plan <plan-path>` or `--target <plan-path>`).
+
+1. Infer validation intent and a unique target from explicit args/flags first, then natural language and repository context. Do not require an inferable slug. Ask `ask_user_question` in the caller for material ambiguity; send insufficient intent to [help](help.md).
+
+## Steps
+
+If DRAFT and no native subagents are available, ask for explicit confirmation in the caller and follow [the inline exception](inline-fallback.md), including a distinct read-only inline Plan Reviewer pass; otherwise stop with a blocker. Never claim an independent review for inline work.
+
+1. Resolve the initiating Git root, absolute PLAN.md and every numbered brief path. If READY, return its status; READY does not require revalidation for go. For DRAFT, fill all placeholders with real values before launch (use `none` where appropriate). Launch a separate frontier/high `diffpi-planner` background agent with ambient capabilities:
+
+```text
+Validate this DRAFT without marking it READY or executing tasks.
+- Exact request: {exact-request}
+- Initiating Git root: {repo-root}
+- Absolute PLAN.md path: {plan-path}
+- Absolute numbered brief paths: {brief-paths}
+- Read PLAN.md, all numbered briefs and durable review evidence. Run a working read-only structural check of the whole current draft; name the capability used or block if none works. Check task ID/title parity, prerequisites/constraints, sole action-labeled fenced `text` Files Affected tree immediately after Objective, ordered tasks and temporally runnable Verify commands. Repair structural errors only within the plan and rerun the structural check.
+- Identify this authoring cycle. If one independent completed whole-plan diffpi-plan-reviewer round already exists for the cycle with valid before/after snapshot evidence, reuse it; never dispatch a second reviewer on repeated validate or after repairs. Otherwise capture every plan file path/hash plus Git HEAD, porcelain status, diff and untracked inventory, then launch at most ONE independent frontier/high diffpi-plan-reviewer background agent. Fill its prompt with the actual absolute plan/brief paths, hashes and Git evidence before dispatch:
+
+  Reviewer task: Read PLAN.md and every numbered brief at {reviewed-plan-paths-and-hashes} with Git evidence {git-head-status-diff-untracked}. Make no mutations. Review structure, parity, phase prerequisites/constraints, Files Affected tree placement, ordered steps, temporally runnable Verify commands, intent/design consistency, risks and lightweight Worker executability. Return completed verdict and findings; each finding includes file, line, BLOCKING/CONSIDER/NOTE severity, reason and concrete fix. Return an explicit empty findings list for PASS. Do not claim source implementation is verified.
+
+- Require the reviewer's actual completed result, not queued/partial/stopped output or self-reported identity. Compare plan hashes and Git HEAD/status/diff/untracked inventory immediately after review. Invalidate the round on reviewer mutation, incomplete evidence or unexplained change. Use any real available dispatch/completion implementation, not one named tool prerequisite.
+- Record the reviewed snapshot, Git evidence, completed verdict, findings and concrete disposition of each finding under References or a linked durable artifact. Repair actionable findings, reread changed files and rerun ONLY the read-only structural check. Record post-fix snapshot separately. Preserve the original BLOCKING verdict; never claim reviewer PASS for repaired content. A later user-initiated change starts a new authoring cycle, but repeated validation does not.
+- Return validation PASS only when structural checks pass, the one completed review round and evidence are valid, every BLOCKING finding has a resolved disposition, and all post-review changes are explained. Otherwise return precise blockers. Leave DRAFT; no background questions.
+```
+
+2. Collect the actual completed result, not only a job ID. Report validation verdict, reviewed and current snapshots, dispositions or blockers. Do not mark READY.

package/skills/review/SKILL.md

@@ -1,15 +1,23 @@
 ---
 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.
 ---
 
 # 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).
+Infer the verb from the request. Route it with its arguments to the selected workflow:
 
-`--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.
+| Command                                                                         | Reference                                    |
+| ------------------------------------------------------------------------------- | -------------------------------------------- |
+| `new [title] [--intent text] [--base branch] [--local]`                         | [new](references/workflows/new.md)           |
+| `auto [target] [--local]`                                                       | [auto](references/workflows/auto.md)         |
+| `address [target] [--local]`                                                    | [address](references/workflows/address.md)   |
+| `publish [target] [--local] [--comment\|--approve\|--request-changes\|--close]` | [publish](references/workflows/publish.md)   |
+| `complete [target] [--local\|--approve\|--reject\|--abandon]`                   | [complete](references/workflows/complete.md) |
+| `merge [target]`                                                                | [merge](references/workflows/merge.md)       |
+| `status [target] [--local]`                                                     | [status](references/workflows/status.md)     |
+| `open [target] [--local]`                                                       | [open](references/workflows/open.md)         |
+| `edit [target] [--local]`                                                       | [edit](references/workflows/edit.md)         |
+| `help`                                                                          | [help](references/workflows/help.md)         |
 
-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.
-
-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.
+Map `create`/`draft` → `new`, `launch` → `auto`, `ready` → `publish`, `close` → `complete`, `land` → `merge`. Route missing or unrecognizable intent → [help](references/workflows/help.md). For substantive work without native subagents, use the selected workflow's [foreground fallback](references/workflows/foreground-fallback.md) only after explicit confirmation.

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

@@ -1,11 +1,23 @@
 # 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.
+## Parse arguments
+
+Accept `address [target] [--local]`. Fuzzy-match the review target/backend from the request and repository. Prefer explicit target/`--local`, then safe inference, then the current-review default. Select local for an explicit working-tree request. Infer commit approval only from an actual user instruction. Call `ask_user_question` only for material ambiguity before launch; return a precise blocker if a new decision arises later.
+
+## Steps
+
+1. Resolve the concrete target/backend/local and review scope with `review_context` without classifying threads. Read [review standards](../review-standards.md). Substitute actual values for every placeholder, including the exact request, resolved review-context target, review scope, issue URL if applicable, and standards; never send raw `{placeholders}`. When native subagents are available, launch a frontier/high `diffpi-reviewer` background subagent with the following self-contained prompt and ambient capabilities:
+
+   ```text
+   Address every thread on this review.
+   - Repository: {absolute repo cwd}; exact request: {exact request}.
+   - Resolved review-context target: {target}; backend: {backend}; local: {local}; review scope: {review scope}; issue URL: {issue URL or none}; approved commit policy: {policy}.
+   - Review standards: {standards}.
+   - Call review_context first; reuse its target/backend/local/cwd. Call review_comments; classify every thread, preserve IDs and report unmatched threads. Apply every relevant requested change now unless explicitly deferred by the user or concretely blocked.
+   - Delegate independent, bounded non-overlapping source/test edits to lightweight/low diffpi-worker agents with ambient capabilities. Each self-contained fenced text task prompt must supply the actual repository, target/backend/local, thread IDs and exact requests, assigned file scope, acceptance checks and no-lifecycle-mutation policy; fill real values before launch, never raw placeholders. Serialize uncertain or overlapping scopes. Keep your source review read-only. Collect completed worker results, inspect actual edits and verification; escalate hard or ambiguous work instead of silently deferring it. Workers must not commit, reply, publish, complete, merge, resolve or mutate review state.
+   - Run review_gates after edits; record failed and skipped checks. For remote source changes, commit after checks and before replies through the user-approved upstream /git commit --no-push workflow (--atomic for separate logical commits). Do not commit without approval. Leave local source edits uncommitted.
+   - Call review_respond for every thread with resolve:false, explicit fixed/answered/unresolved outcome and verification evidence. Do not claim blocked work was delivered. Keep questions and all threads open for user resolution. Optionally call review_launch_ui for local replies.
+   - Never delete or resolve threads, publish, complete or merge. Report fixed, committed, answered, unresolved, skipped and failed counts, unmatched replies, gate evidence and blockers; resolved count is zero. Preserve local replies and thread state between runs.
+   ```
+
+2. If no native subagents are available, follow [foreground fallback](foreground-fallback.md) before classifying threads or editing. Only after explicit confirmation, perform the address steps above inline, including source/test edits directly where needed (do not invent Worker results), checks, approved commit policy, and `review_respond(resolve:false)` for every thread; report unresolved and blocked work honestly. Otherwise verify the attached launch. Stop on failure; report the actual completed child outcome, not merely its queued ID or claim of success.

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

@@ -1,18 +1,25 @@
 # 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.
+## Parse arguments
+
+Accept `auto [target] [--local]`. Fuzzy-match review intent and infer the current branch, PR/MR or working-tree target/backend from the request and repository. Prefer explicit arguments/flags, then safe inference, then current-review defaults. Select local for an explicit working-tree request. Call `ask_user_question` only for material ambiguity before launch; return a precise blocker if a new decision arises later.
+
+## Steps
+
+1. Resolve the concrete target/backend/local and diff scope with `review_context` without analyzing the diff. Read [review standards](../review-standards.md). Substitute actual values for every placeholder, including the exact request, resolved review-context target, diff scope, issue URL if applicable, and standards; never send raw `{placeholders}`. When native subagents are available, launch a frontier/high `diffpi-reviewer` background subagent with the following self-contained prompt and ambient capabilities:
+
+   ```text
+   Review this change without editing source.
+   - Repository: {absolute repo cwd}; exact request: {exact request}.
+   - Resolved review-context target: {target}; backend: {backend}; local: {local}; diff scope: {diff scope}; issue URL: {issue URL or none}; approved policy: {policy}.
+   - Review standards: {standards}.
+   - Call review_context first; reuse its target/backend/local/cwd. Reject unsupported forge, missing integration or unavailable local base without switching backend.
+   - Use review_status if needed to distinguish an existing review. Call review_new for a new local session or remote draft PR/MR; call review_edit for an existing review.
+   - Run review_gates, then review_diff. Judge intent, correctness, negative/security paths, scope and duplicate findings. Record failed and skipped format/lint/test/subject/CI checks; stop with evidence if the diff is unavailable.
+   - Stage changed-file-and-line-grounded BLOCKING, CONSIDER or NOTE findings with review_submit; submit [] if clean. Include overall issues and not-verified checks where needed. Keep remote findings pending and local findings in draft.
+   - Do not edit source, publish, complete, merge or resolve threads.
+   - Delegate bounded independent checks when useful, with self-contained task prompts and ambient capabilities. The plan's exactly-one independent review limit does not apply to PR/MR code review.
+   - Verify and report artifact, backend, gates, finding count and blockers.
+   ```
+
+2. If no native subagents are available, follow [foreground fallback](foreground-fallback.md) before analysis or creation. Only after explicit confirmation, execute the review steps above inline without source edits, following the same standards and staging findings via `review_submit`; label the result foreground fallback. Otherwise verify the attached launch. Stop on failure; report the actual completed child outcome, not merely its queued ID or claim of success.