@webpresso/agent-kit 3.1.25 → 3.1.28

package/catalog/AGENTS.md.tpl

@@ -54,6 +54,8 @@ Catalog-owned surfaces:
 - Reuse nearby utilities and patterns before adding new abstractions.
 - Apply DRY, SOLID, YAGNI, and KISS.
 - No hardcoded relative paths in executable code or config; derive from an explicit absolute anchor.
+- Efficiency: MCP `wp_*` over shell; `ultragoal`/`/pll`; `/verify` local vs
+  `--merge-ready` (1 outside voice); `fix_budget`=1.
 
 Hook invariant: global hooks use the canonical contract; skill hooks never
 project into host settings. Bound hot paths; do not raise timeouts or hide work
@@ -62,16 +64,9 @@ asynchronously.
 ## Verify
 
 Before claiming completion, run the narrowest checks that prove the change:
-
-- agent-kit MCP tools first when available; otherwise the repo wrapper
-- typecheck
-- lint / format check
-- affected tests
-- repo policy checks such as `verify:paths` / `verify:secrets`
-- docs or blueprint validation when docs/plans changed
-- `wp sync --check` after template/catalog changes
-
-If a gate fails, fix root cause or record the blocker with evidence.
+MCP/`wp` quality tools, typecheck, lint/format, affected tests, policy checks,
+docs/blueprint validation when those changed, and `wp sync --check` after
+template/catalog changes. On failure, fix root cause or record the blocker.
 
 ## Communicate
 
@@ -149,6 +144,7 @@ Full details: `.agent/rules/package-conventions.md`
 ## Tech stack
 
 {{TECH_STACK}}
+
 <!-- <<< managed by webpresso (planning-and-release) -->
 
 <!-- >>> user-owned (escalation-map) -->

package/catalog/agent/commands/verify.md

@@ -1,6 +1,6 @@
 ---
-description: "Post-implementation quality gate that verifies work is actually done, runs the folded TPH/test-quality audit, cleans up legacy/backward-compat/dead-code garbage left behind, refreshes affected docs, and requires outside-model approval evidence before merge-ready claims. Use after implementing a feature or fix, before claiming done, or when finalizing a blueprint."
-argument-hint: "<target> [--full] where target is: package|file|plan-slug|all"
+description: "Post-implementation quality gate: local checks by default; --merge-ready requires exactly one outside-voice approval. Runs TPH/test-quality audit, dead-code sweep, and docs refresh. Use after implementing a feature or fix, before claiming done, or when finalizing a blueprint."
+argument-hint: "<target> [--full|--merge-ready] where target is: package|file|plan-slug|all"
 allowed-tools: Bash, Read, Write, Edit, Glob, Grep, Task, TodoWrite
 ---
 

package/catalog/agent/rules/changeset-release.md

@@ -180,7 +180,13 @@ for the current repository and package configuration contract.
    `npm view <package> version`. For consumer setup smoke, use
    `vp install -g @webpresso/agent-kit@latest`, `wp setup`, and
    `wp sync --check`.
-6. After the OIDC publish path succeeds, set npm package publishing access to
+6. Version Packages PRs are authored via the **webpresso-dev** App installation
+   token in `release.yml` (not bare `GITHUB_TOKEN`). If a PR still has no WP
+   check / CI is `action_required` with zero jobs (legacy bot author or App
+   mint failure), follow
+   [`docs/runbooks/version-packages-bot-ci.md`](../../../docs/runbooks/version-packages-bot-ci.md)
+   (`gh run rerun` or Approve workflows). Do not admin-merge without WP check.
+7. After the OIDC publish path succeeds, set npm package publishing access to
    require two-factor authentication and disallow tokens, then revoke obsolete
    automation tokens. Do not remove a credential that another verified release
    path still needs.

package/catalog/agent/rules/workflow-skills-routing.md

@@ -73,7 +73,10 @@ Map routing intent like this:
   `deep-research`
 - debugging and regressions → `investigate` then `fix`
 - bounded cleanup after behavior is green → `ai-deslop`
+- multi-task / parallel execute → `ultragoal` + `/pll` (ready-queue, worktrees)
+- local completeness → `/verify`; merge-ready outside voice → `/verify --merge-ready`
+  (exactly one sequential outside reviewer unless user sets N)
 
-Use `wp_*` tools for tests, lint, typecheck, audits, blueprint execution, and
-quality gates. Use the curated review skills for plan critique, outside voice,
-and pre-landing review when explicitly requested or clearly useful.
+Use the full `wp_*` MCP surface for tests, lint, typecheck, audits, session memory,
+ultragoal, worktrees, PRs, and quality gates — not shell reimplementations. Use
+curated outside-voice skills only within `review_budget` (default 0 local / 1 merge-ready).

package/catalog/agent/skills/autopilot/SKILL.md

@@ -5,9 +5,9 @@ title: Autopilot
 status: active
 scope: repo
 applies_to: [agents]
-related: [goal, plan-refine, verify, testing-philosophy]
+related: [goal, plan-refine, verify, testing-philosophy, ultragoal, pll, fix]
 created: "2026-07-10"
-last_reviewed: "2026-07-10"
+last_reviewed: "2026-07-21"
 name: autopilot
 description: "Drive a brief through the bounded native goal pipeline."
 argument-hint: "<brief|force: brief>"
@@ -15,25 +15,62 @@ argument-hint: "<brief|force: brief>"
 
 # Autopilot
 
-Drive an approved brief through `plan -> execute -> qa -> validate -> land -> complete` using `wp ultragoal run` and the current handoff.
+Drive an approved brief through `plan -> execute -> qa -> validate -> land -> complete`
+using `wp_ultragoal_run` / `wp ultragoal run` and the current handoff.
+
+## Outside-voice (required)
+
+After each ultragoal **phase or plan-gate milestone**, run an **OpenCode Go** outside-voice review and pick the model by purpose (plan critique → DeepSeek Pro; coding quality → Kimi Code first; cheap recheck → DeepSeek Flash). Resolve IDs from live `opencode models opencode-go`. Lifecycle authority only via converged `wp review gate` — never self-approve. Full protocol: the `ultragoal` skill. Respect `review_budget` (default one sequential path; no multi-host stampede).
 
 ## Vague gate
 
-A brief is anchored when it includes a file path, symbol, issue number, test name, or numbered steps. Route any unanchored brief through `plan-refine` before execution. A leading `force:` is the only explicit bypass; strip it before creating the goal and record the bypass in the blueprint.
+A brief is anchored when it includes a file path, symbol, issue number, test name, or numbered steps
+(blueprint slug and explicit budgets also count). Route any unanchored brief through
+`plan-refine` before execution.
+
+**Reject** (unless rewritten with scope + budgets): “complete all”, “full autopilot”,
+“go to sleep”, “elegantly merge everything” without a named blueprint/PR set.
+
+A leading `force:` is the only explicit bypass; strip it before creating the goal and
+record the bypass in the blueprint.
+
+Default budgets if the user omits them: `concurrency=4`, `fix_budget=1`,
+`review_budget=1`, no `/loop`. See `ultragoal` skill.
+
+## Tooling map
+
+| Pipeline step        | Tools                                                                                                                                              |
+| -------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Plan                 | `plan-refine`, `wp_blueprint_*`, `wp_session_capture` for decisions                                                                                |
+| Create controller    | `wp_ultragoal_new`, `wp_worktree`                                                                                                                  |
+| Execute              | ready-set via blueprint tools; `/pll` or parallel subagents; `wp_session_context` for delegates; `wp_blueprint_task_verify` only to complete tasks |
+| Opportunistic repair | `/fix` up to `fix_budget`; else handoff backlog                                                                                                    |
+| QA                   | `wp_qa` / `wp_lint` / `wp_typecheck` / `wp_test`; PR checks via `wp_pr_status` / `wp_pr_wait`                                                      |
+| Validate             | one outside voice if merge-bound (OpenCode Go by purpose, or claude/codex/grok); `wp review gate` for authority                                    |
+| Land                 | `wp_pr_upsert`, green required checks, merge + owner cleanup                                                                                       |
+| Blocked / stop       | `wp_ultragoal_handoff` ≤40 lines; `wp_ultragoal_cancel` if abandoned                                                                               |
 
 ## Pipeline
 
-1. Plan: refine blueprints and satisfy provenance-backed promotion approvals.
-2. Execute: implement current ready tasks; use only `wp_blueprint_task_verify` to mark them done.
-3. QA: run affected checks and `wp qa`; preserve normalized failure evidence.
-4. Validate: obtain distinct verification and code-review evidence and resolve findings. Each lane appends a tracked `reviews.md` record in one of these exact forms:
+1. **Plan:** refine blueprints and satisfy provenance-backed promotion approvals.
+2. **Execute:** implement current **ready** tasks in parallel up to `concurrency`; use only
+   `wp_blueprint_task_verify` to mark them done.
+3. **QA:** run affected checks and `wp_qa`; preserve normalized failure evidence. Prefer
+   PR-bound CI when a PR exists.
+4. **Validate:** obtain verification + code-review evidence within `review_budget`. Each
+   lane appends a tracked `reviews.md` record in one of these exact forms:
 
    ```text
    <!-- wp:goal-validation {"kind":"verify","reviewer":"<identity>","artifact":"<tracked-path>"} -->
    <!-- wp:goal-validation {"kind":"code-review","reviewer":"<different-identity>","artifact":"<tracked-path>"} -->
    ```
 
-5. Land: require green PR checks, complete the blueprint in the same PR, merge, and run owner cleanup.
-6. Complete: stop only when `wp ultragoal run` records terminal evidence.
+5. **Land:** require green PR checks, complete the blueprint in the same PR, merge, and
+   run owner cleanup.
+6. **Complete:** stop only when `wp_ultragoal_run` records terminal evidence.
 
-Resume from durable state after interruption. Obey `WP_ULTRAGOAL_DISABLE=1`, iteration/error/validation caps, and repository ownership. The pipeline must never self-approve, directly mark tasks done, bypass evidence, or push to main. Keep every loop bounded and never increase timeouts.
+Resume from durable state after interruption. Obey `WP_ULTRAGOAL_DISABLE=1`,
+iteration/error/validation caps, and repository ownership. Never self-approve, directly
+mark tasks done, bypass evidence, push to main, or increase timeouts (keep every loop bounded and never increase timeouts). After every phase
+transition recorded by `wp ultragoal run`, obtain a fresh OpenCode Go outside review
+before treating the milestone as closed (see Outside-voice above and the `ultragoal` skill).

package/catalog/agent/skills/claude/SKILL.md

@@ -8,6 +8,13 @@ license: MIT
 
 Use when a non-Claude host needs Claude to review a diff, challenge a plan, or answer a focused repo question. Keep it bounded/read-only unless asked otherwise, and report Claude output as advice, not verified fact.
 
+## Single-shot budget (anti-stampede)
+
+- Default: **one** review invocation per request.
+- Do **not** spawn parallel Claude + Codex + Grok + OpenCode reviews unless the user set `review_budget`/`N` > 1.
+- Prefer `wp review run` / `wp review gate` over hand-rolled multi-agent loops.
+- Bounded payload only (see below). Split large diffs across sequential calls, never unbounded whole-PR dumps.
+
 ## Auth check
 
 Use local Claude CLI login directly; do not route through Anthropic API-key env vars.

package/catalog/agent/skills/codex/SKILL.md

@@ -8,6 +8,13 @@ license: MIT
 
 Use this skill from Claude or another non-Codex host when the user wants Codex to independently review a diff, challenge a plan, or answer a repo question. Keep Codex read-only by default and treat its answer as external advice until independently verified.
 
+## Single-shot budget (anti-stampede)
+
+- Default: **one** review invocation per request.
+- Do **not** fan out parallel multi-host review matrices unless the user set `review_budget`/`N` > 1.
+- Prefer `wp review run` / `wp review gate` over spawn/wait agent loops for review.
+- Keep prompts bounded; no whole-repo paste.
+
 ## Auth check
 
 ```bash

package/catalog/agent/skills/fix/SKILL.md

@@ -7,7 +7,7 @@ scope: repo
 applies_to: [agents]
 related: [verify, testing-philosophy]
 created: "2026-05-13"
-last_reviewed: "2026-05-22"
+last_reviewed: "2026-07-21"
 name: fix
 description: "Root-cause fix workflow that runs investigate first when diagnosis or failing proof is still missing."
 argument-hint: '<target> where target is: file|symptom|error|test|"free-text description"'
@@ -23,18 +23,43 @@ This command turns "please fix it well" into an enforceable workflow: diagnose
 first, repair at the owner, prove the repair, and escalate to `/verify` when
 the blast radius is broader than a local fix.
 
+## Tooling map
+
+| Need                   | Prefer                                                                      |
+| ---------------------- | --------------------------------------------------------------------------- |
+| Reproduce / large logs | `wp_session_execute`, `wp_session_batch_execute`, `wp_session_execute_file` |
+| Recall prior evidence  | `wp_session_search`, `wp_session_restore`, `wp_session_retrieve`            |
+| Capture decisions      | `wp_session_capture` (do not paste full reports back as user text)          |
+| Scoped proof           | `wp_test`, `wp_lint`, `wp_typecheck`, or `wp_qa`                            |
+| Audits                 | `wp_audit` / `wp_audits`                                                    |
+| Worktree isolation     | `wp_worktree` / `wp blueprint start` — never thrash primary checkout        |
+| PR follow-up           | `wp_pr_status`, `wp_pr_upsert` when landing the fix                         |
+
 ## Non-negotiable invariants
 
 1. **Root cause, not symptom.** Trace the failure to the invariant that actually broke. Do not patch callers when the owner is fixable.
 2. **Loud failures, no silent fallbacks.** No default shims, sentinel returns, or catch-and-continue behavior that hides missing config, bad state, or broken boundaries.
-3. **Use the repo's real execution surface.** Prefer repo-owned wrappers and injected routing guidance over host-specific tool assumptions. If the repo exposes quality wrappers, use them. Use bounded inspection paths for large-output investigation.
+3. **Use the repo's real execution surface.** Prefer MCP `wp_*` tools and repo wrappers over host Bash for search/test/lint. Use bounded session-memory paths for large output.
 4. **Regression proof is mandatory.** Add or strengthen a test or other reliable proof that would fail against the old behavior.
 5. **Raising timeouts is not a fix.** If a timeout fires, investigate the bottleneck. Only raise a bound when the repo already documents that workload and you can cite measurement.
 6. **Zero suppressions, zero papering over.** No lint disables, ts-ignore, compat aliases, or "temporary" branches to sneak the fix through.
 7. **Minimal correct diff.** Update every consumer of a changed contract in the same change, but do not bundle unrelated cleanup.
+8. **Primary checkout is sacred.** If HEAD is detached, primary is dirty with unrelated work, or you are not on a managed worktree for non-trivial edits → **stop** and move to `wp_worktree` / blueprint owner. Never leave the primary checkout broken.
+
+## Opportunistic fix budget (when called from ultragoal / autopilot / pll)
+
+- At most **`fix_budget` (default 1)** pre-existing issues per controller phase.
+- Each must have: named invariant, failing proof, owning path.
+- If the repair needs its own blueprint or expands epic scope → **handoff backlog**, do not inline.
+- Additional discoveries: list in the final report; do not thrash.
 
 ## Protocol
 
+### Step 0a — Worktree preflight
+
+Before editing: confirm you are on a managed worktree or an explicitly allowed branch.
+If the primary checkout is dirty/detached with unrelated state, stop and isolate first.
+
 ### Step 0 — Run the investigate phase when evidence is missing
 
 Before editing, check whether the current context already contains all of the
@@ -94,17 +119,17 @@ Do not keep production code written before the test as "reference". If you wrote
 
 Run the narrowest checks that prove the repaired behavior on the real repo surface:
 
-- targeted test(s) for the repaired path
-- targeted lint/typecheck/build checks for changed files or packages
-- any boundary-specific verification the repo requires for the touched surface
+- `wp_test` / targeted tests for the repaired path
+- `wp_lint` / `wp_typecheck` for changed surfaces
+- `wp_qa` only when the blast radius needs the bookend
 
 Rules:
 
-- Prefer repo-owned wrappers or routed quality tools over raw host-specific commands.
-- Reuse fresh logs if the repo auto-saves them; do not re-run long commands just to re-read output.
+- Prefer MCP `wp_*` over raw host Bash.
+- Reuse fresh logs / session-memory indexed output; do not re-run long commands just to re-read.
 - Read the exit code and summary before making a claim.
 
-Escalate to `/verify <target>` when any of these are true:
+Escalate to `/verify <target>` (local) or `/verify <target> --merge-ready` when any of these are true:
 
 - the fix crosses packages
 - the fix changes a public or shared contract

package/catalog/agent/skills/grok/SKILL.md

@@ -8,6 +8,13 @@ license: MIT
 
 Use when a non-Grok host needs Grok Build to review a diff, challenge a plan, or answer a focused repo question. Keep it read-only by default. A provenance-backed Grok approval is first-class and satisfies the blueprint strong-reviewer gate alone, with the same rejection authority as Claude or Codex.
 
+## Single-shot budget (anti-stampede)
+
+- Default: **one** review invocation per request.
+- Do **not** run parallel multi-host review swarms unless the user set `review_budget`/`N` > 1.
+- Prefer `wp review run` / `wp review gate --provider grok` for lifecycle authority.
+- Bounded prompts only.
+
 ## Auth / binary
 
 ```bash

package/catalog/agent/skills/investigate/SKILL.md

@@ -17,10 +17,21 @@ flaky behavior, or confusing symptom before editing code.
 - Stop once you can name the broken invariant, show the failing proof, and
   point at the owner that should be repaired.
 
+## Tooling map
+
+| Need                   | Prefer                                                           |
+| ---------------------- | ---------------------------------------------------------------- |
+| Reproduce / large logs | `wp_session_execute`, `wp_session_batch_execute`                 |
+| Large files            | `wp_session_execute_file`                                        |
+| Prior continuity       | `wp_session_search`, `wp_session_restore`, `wp_session_retrieve` |
+| Capture findings       | `wp_session_capture` (short pointer, not full paste-back)        |
+| Proof runs             | `wp_test`, `wp_qa`, `wp_lint`, `wp_typecheck`                    |
+| Code search/read       | host Grep/Read first; avoid shell-as-IDE                         |
+
 ## Workflow
 
 1. Reproduce or capture the failure.
-   - Run the exact failing command or trace the exact user path.
+   - Run the exact failing command or trace the exact user path (prefer `wp_session_execute`).
    - Keep the evidence that matters: error text, failing assertion, exit code,
      log path, or boundary mismatch.
 2. Read the whole boundary.

package/catalog/agent/skills/pll/SKILL.md

@@ -5,78 +5,83 @@ title: PLL Skill — Blueprint-Aware Parallel Execution
 status: active
 scope: repo
 applies_to: [agents]
-related: []
+related: [ultragoal, autopilot, team]
 created: "2026-05-07"
-last_reviewed: "2026-05-07"
+last_reviewed: "2026-07-21"
 name: pll
+description: "Blueprint-aware parallel execution: ready-queue, max-parallel lanes, cascade-skip."
 ---
 
 # PLL Skill — Blueprint-Aware Parallel Execution
 
-Use this skill when the user invokes `/pll` or asks for Blueprint-aware parallel execution.
+Use when the user invokes `/pll` or asks for Blueprint-aware parallel execution.
 
-`/pll` is not a standalone runner. It is the operator-facing adapter over the same shared execution model used by `wp blueprint exec`: both surfaces consume the same Blueprint-backed launch spec, backend vocabulary, and runtime-state bridge, but `/pll` stays manual and operator-facing.
-
-`/pll`:
-
-1. understands Blueprint/task dependencies
-2. updates `wp blueprint` lifecycle state honestly
-3. delegates generic parallel fan-out to the engine layer such as `$ultrawork` or host-native subagents
+`/pll` is the operator-facing adapter over the same shared execution model as
+`wp blueprint exec`: Blueprint-backed launch specs, backend vocabulary, and
+runtime-state bridge. `/pll` stays manual and operator-facing; `ultragoal` is the
+durable multi-phase controller that should call the same ready-queue rules.
 
 ## Responsibilities
 
-1. **Input parsing**
-   - Accept inline task lists, comma-separated strings, or file paths.
-   - Treat blueprint paths under `blueprints/` as lifecycle-backed execution.
-2. **Blueprint lifecycle**
-   - Use `wp blueprint start`, `wp blueprint task ...`, and `wp blueprint finalize` for durable state.
-   - Never use `wp blueprint move` as the normal execution primitive.
-   - Keep the lifecycle semantics aligned with `wp blueprint exec`; do not invent a separate `/pll`-only plan model.
-3. **Dependency-aware batching**
-   - Compute ready work from explicit dependencies and obvious blocking relationships.
-   - Prioritize critical-path or high-fan-out work when choosing the next batch.
-4. **Engine delegation**
-   - Hand independent work to the current engine layer (`$ultrawork`, subagents, or equivalent runtime-native parallel lanes).
-   - Do not promise a fixed active-agent count across runtimes.
-5. **Verification discipline**
-   - Require repo verification before marking blueprint tasks complete.
-6. **Shared execution model**
-   - Treat `/pll` as the interactive/manual front door for the same control-plane contract that `wp blueprint exec` uses.
-   - Reuse the same backend names, progress bridge semantics, and truthfulness rules.
-
-## Roadmap-Aware Lane Picking
-
-When no explicit task list is supplied, ground lane selection in `wp blueprint list` before inventing work:
+1. **Input parsing** — inline task lists, files, or blueprint paths under `blueprints/`.
+2. **Blueprint lifecycle** — `wp blueprint start`, task tools, finalize; never `wp blueprint move`
+   as the normal primitive. Prefer MCP: `wp_blueprint_list` / `get` / `context` /
+   `put` / `transition` / `task_verify`.
+3. **Ready-queue (max parallel)** — compute tasks with satisfied deps; print the ready-set
+   before launching; fill up to `concurrency` (default 4, max 8; user can set `--max`).
+4. **Engine delegation** — independent work → host subagents / `$ultrawork` / worktrees via
+   `wp_worktree`. Before each delegate: `wp_session_context` (no full-history paste).
+5. **Verification** — complete tasks only with `wp_blueprint_task_verify` + repo proof
+   (`wp_qa` / `wp_test` / targeted tools). Large commands → `wp_session_execute` /
+   `wp_session_batch_execute`.
+6. **Shared model** — same control-plane contract as `wp blueprint exec` and ultragoal execute.
+
+## Ready-queue algorithm
+
+```text
+ready = tasks where status=todo and all Depends are done
+while ready or in_progress:
+  launch min(len(ready), concurrency - in_progress) implementers in worktrees
+  on success → verify with evidence → unlock dependents into ready
+  on hard fail → block task, cascade-skip dependents that require it, continue others
+```
 
-1. Prefer active `ROADMAP` rows and pick the next `planned` `CHILD` row whose `depends_on:` chain is satisfied.
-2. Treat `ORPHANS` as fallback work only when no roadmap child is actionable.
-3. Keep the heuristic discoverable and auditable: `wp audit roadmap-links` checks bidirectional roadmap/child links, while `wp audit blueprint-lifecycle` checks lifecycle placement.
-4. If command output changes, update `/pll` guidance and the shared blueprint output contract together.
+Prioritize critical-path / high-fan-out tasks when choosing the next batch.
 
 ## Concurrency Limits
 
-| Scope              | Guidance                                                                  |
-| ------------------ | ------------------------------------------------------------------------- |
-| Default batches    | Use the smallest parallelism that still keeps safe independent lanes busy |
-| Test-heavy tasks   | Keep concurrency conservative                                             |
-| Build/deploy tasks | Keep concurrency conservative                                             |
+| Scope                       | Guidance                                     |
+| --------------------------- | -------------------------------------------- |
+| Default                     | Keep safe independent lanes busy (default 4) |
+| Hard max                    | 8 unless the user explicitly raises          |
+| Test-heavy / build / deploy | Conservative (often 1–2)                     |
+| Shared file ownership       | Serialize or merge tasks — never two writers |
 
 ## Deadlock and Failure Handling
 
-- If no tasks remain ready but some are blocked, report the blocking tasks and their dependencies.
-- Failed tasks stay blocked with reasons; downstream work remains blocked unless explicitly safe to continue.
-- If lifecycle mutation fails, stop instead of continuing with stale plan state.
+- No ready work but blocked tasks remain → report blockers + deps; stop or handoff.
+- Failed tasks stay blocked with reasons; dependents cascade-skipped unless safe alone.
+- Lifecycle mutation failure → stop (no stale plan execution).
+- Capture decisions with `wp_session_capture`; resume via `wp_session_search` / `restore`.
+
+## Roadmap-Aware Lane Picking
+
+When no explicit task list is supplied, ground selection in `wp blueprint list`:
+
+1. Prefer active `ROADMAP` rows; next `planned` `CHILD` with satisfied `depends_on:`.
+2. `ORPHANS` only when no roadmap child is actionable.
+3. Audits: `wp audit roadmap-links`, `wp audit blueprint-lifecycle`.
 
 ## When **NOT** to use
 
-- Small, strictly serial work where `/plan` or direct execution is simpler.
-- Situations where you only need generic parallel fan-out and do not need Blueprint lifecycle/state awareness; use `$ultrawork` directly there.
+- Small strictly serial work → direct execution or `/fix`.
+- Generic fan-out without blueprint lifecycle → host-native parallel only.
+- Overnight multi-phase goals → `ultragoal` / `autopilot` (which should still use these rules).
 
-## Quick Start Examples
+## Quick Start
 
 ```bash
 /pll "lint auth, lint utils, typecheck api [depends: lint auth], test api [depends: typecheck api]"
 /pll tasks.md --max=6
-/pll blueprints/in-progress/new-launch.md
 /pll blueprints/in-progress/new-launch/_overview.md
 ```

package/catalog/agent/skills/team/SKILL.md

@@ -7,7 +7,7 @@ scope: repo
 applies_to: [agents]
 related: [autopilot, goal, plan-refine, verify]
 created: "2026-07-13"
-last_reviewed: "2026-07-13"
+last_reviewed: "2026-07-21"
 name: team
 description: "Coordinate multiple dashboard-backed agent sessions on one task."
 argument-hint: "<brief|role plan>"
@@ -18,32 +18,49 @@ argument-hint: "<brief|role plan>"
 Use `team` when the work needs coordinated parallel lanes with a leader-owned
 task list, explicit handoffs, and independent verification. Prefer native
 subagents for small bounded lookups; use `team` when the parallel work should be
-visible, durable, and operator-controllable from `wp dash`.
+visible, durable, and operator-controllable from `wp dash`. Prefer `ultragoal` +
+`/pll` when the work is blueprint-owned and does not need multi-provider dashboard
+lanes.
+
+## Tooling map
+
+| Need                  | Prefer                                                          |
+| --------------------- | --------------------------------------------------------------- |
+| Dashboard / sessions  | `wp dash`, `wp_fleet_status`, `wp_worker_tail`                  |
+| Worktrees             | `wp_worktree` per lane                                          |
+| Context-light handoff | `wp_session_context` (required before spawn — no history paste) |
+| Continuity            | `wp_session_capture` / `search` / `restore`                     |
+| Blueprint tasks       | `wp_blueprint_task_verify` only for completion                  |
+| QA                    | `wp_qa` / targeted `wp_test` / `wp_lint` / `wp_typecheck`       |
+| PR                    | `wp_pr_upsert` / `wp_pr_status` / `wp_pr_wait`                  |
 
 ## Protocol
 
 1. Start from a grounded brief or an approved blueprint. If scope is vague, run
-   `plan-refine` first and define task lanes, shared files, and verification.
+   `plan-refine` first and define task lanes, shared files, budgets, and verification.
 2. Open or reuse `wp dash` and launch the provider sessions needed for the
    lanes. Direct `wp claude`, `wp codex`, and `wp opencode` commands are
    expected to enter the dashboard in interactive terminals.
 3. Assign one owner per lane. Include the task, allowed files or surfaces,
    expected output, verification command, and blocker-report rule.
-4. Keep one lane or leader pass responsible for integration and evidence.
+4. Before each worker spawn, build a bounded manifest with `wp_session_context`
+   (objective, constraints, evidence refs, remaining steps). Never copy parent transcripts.
+5. Keep one lane or leader pass responsible for integration and evidence.
    Workers report findings, patches, tests, and unresolved risks; they do not
    self-approve or mark blueprint tasks complete.
-5. Integrate only after checking shared-file conflicts, updated assumptions,
+6. Integrate only after checking shared-file conflicts, updated assumptions,
    and verification evidence. Use `wp_blueprint_task_verify` for task completion
    when a blueprint owns the work.
-6. Stop when every lane is complete, cancelled, or explicitly blocked and the
-   leader has recorded verification evidence.
+7. Stop when every lane is complete, cancelled, or explicitly blocked and the
+   leader has recorded verification evidence (≤40-line handoff if blocked).
 
 ## Coordination Rules
 
 - Use a single source of truth for assignments: the blueprint, goal handoff, or
   leader-maintained task list.
-- Require ACK-style lane starts for shared files, dependency boundaries, or
-  handoffs.
+- Cap concurrency (default 4). Cascade-skip dependents of hard failures.
+- Opportunistic `/fix` uses `fix_budget` (default 1) total across the team, not per lane.
+- Require ACK-style lane starts for shared files, dependency boundaries, or handoffs.
 - Reassign or narrow blocked lanes instead of letting work drift.
 - Escalate changed assumptions before widening scope.
 - Never bypass review provenance, push to main, self-approve, or increase