@webpresso/plugin-codex 0.0.4

package/skills/browse/SKILL.md

@@ -0,0 +1,25 @@
+---
+name: browse
+description: "Browser/page inspection via Webpresso Playwright: inspect DOM, console, network basics, screenshots, and findings."
+license: MIT
+allowed-tools:
+  - Read
+  - Glob
+  - Grep
+  - Bash
+---
+
+# Browse
+
+Use `wp browser doctor` first if browser availability is unknown; if it reports a missing browser, run `wp browser ensure chromium`. Prefer repo-local preview or dev-server URLs; if none are discoverable, ask for a URL.
+
+## Read-only inspection
+
+The `allowed-tools` frontmatter is an audited disclosure for supported hosts;
+pretool-guard remains the enforced mutation backstop when a host does not prove
+skill-frontmatter enforcement.
+
+1. Identify the URL and whether headed or headless mode is needed.
+2. Use `wp browser open <url> --json` for a lightweight smoke snapshot, or a project Playwright test for deeper flows.
+3. Report URL, title, status evidence, console/page errors when available, and any screenshots/artifacts.
+4. Do not mutate app data unless the user explicitly asks for a mutating browser flow.

package/skills/claude/SKILL.md

@@ -0,0 +1,186 @@
+---
+name: claude
+description: "Claude CLI outside-voice wrapper for review, adversarial challenge, or consultation from non-Claude hosts."
+license: MIT
+---
+
+# Claude outside voice
+
+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 MCP `wp_review_run`, then the `wp review run` CLI fallback, over hand-rolled multi-agent loops.
+- Bounded payload only (see below). Split large diffs across sequential calls, never unbounded whole-PR dumps.
+
+## Primary path: the `wp_review_run` MCP tool
+
+When the webpresso MCP server is available, call `wp_review_run` exactly once
+instead of any bash block below. It is the same `wp review run` typed runtime,
+called in-process, and takes a `prompt` string without `--prompt-file` bookkeeping.
+Use the default review stage.
+
+```jsonc
+// wp_review_run MCP tool call
+{
+  "prompt": "<diff summary + what to look for>",
+  "provider": "claude",
+  // model, effort, artifactRoot, idleSeconds, and stage are optional and
+  // default the same way the `wp review run` CLI does. The default stage is
+  // review.
+}
+```
+
+Use the requested provider for this invocation. Do not retry, use provider
+fallback, or rotate accounts within the invocation. Never shell into a
+provider CLI when MCP is available; that bypasses typed artifact capture under
+`.webpresso/reviews`.
+
+For long-running reviews, prefer the async MCP path: call `wp_review_run` with
+`"provider": "claude"` and `"background": true`, then poll `wp_review_wait`
+with the returned `runId`. Do not solve MCP transport limits by inflating
+synchronous review timeouts.
+
+The bash blocks in this skill (below) are the **MCP-unavailable fallback only**
+— use them when the webpresso MCP server itself is not reachable in the current
+host, not as a provider-fallback mechanism.
+
+## MCP-unavailable fallback: auth check
+
+Use local Claude CLI login directly; do not route through Anthropic API-key env vars.
+
+```bash
+AUTH_STATUS_FILE=$(mktemp -t wp-claude-auth.XXXXXX)
+trap 'rm -f "$AUTH_STATUS_FILE"' EXIT
+if ! claude auth status --json >"$AUTH_STATUS_FILE" 2>/dev/null; then
+  if ! claude auth status >"$AUTH_STATUS_FILE" 2>/dev/null; then
+    echo "CLAUDE_AUTH=missing: run claude auth login with the intended Claude Max account"
+    exit 1
+  fi
+fi
+if grep -E '"(authenticated|loggedIn|success)"[[:space:]]*:[[:space:]]*true' "$AUTH_STATUS_FILE" >/dev/null; then
+  echo "CLAUDE_AUTH=cli-login"
+else
+  echo "CLAUDE_AUTH=missing: claude auth status did not report a recognized Claude CLI login"
+  exit 1
+fi
+```
+
+## MCP-unavailable fallback: portable prompt file
+
+Use a suffix-free `mktemp -t` pattern so macOS and Linux both work:
+
+```bash
+PROMPT_FILE=$(mktemp -t wp-claude-review.XXXXXX)
+trap 'rm -f "$PROMPT_FILE"' EXIT
+```
+
+## Dashboard helper relation
+
+When this skill runs under `wp dash`, record the outside-voice lifecycle with
+`wp dash-helper-start --provider claude --role reviewer` and
+`wp dash-helper-complete --provider claude --role reviewer --outcome <completed|failed>`
+using the actual terminal outcome and artifact path.
+Outside the dashboard, skip helper emission. Claude's managed native subagent
+lifecycle is not parent-linked; this unsupported coverage must stay explicit,
+and completion must never be inferred from transcript text or timing.
+
+## Modes
+
+### Review
+
+Use single-file / single-question first for any non-trivial diff. Do not send a whole PR unless it already fits within the bounded payload below.
+
+**Model policy:** leave `CLAUDE_REVIEW_MODEL` unset unless the user requested a
+specific Claude model (for example `fable` for a lighter advisory pass). When it
+is unset, `wp review run` lets the Claude CLI choose its own default by omitting
+`--model`. The blueprint promotion/completion approval gate
+(`catalog/agent/rules/pre-implementation.md`) validates reviewer identity
+(`claude`/`codex`/`grok`/an OpenCode-Go model), not the reviewed model string, so do not
+claim the gate rejects a different Claude model.
+
+#### Bounded prompt payload
+
+Always include:
+
+- current branch and base branch
+- `git diff --stat`
+- changed file list
+- one targeted file diff or one narrow snippet/hunk only, capped to a fixed size
+
+Prefer ~12 KB or ~200 lines per call. Split large reviews instead of raising the cap.
+
+```bash
+BASE_BRANCH=${BASE_BRANCH:-origin/main}
+CURRENT_BRANCH=$(git rev-parse --abbrev-ref HEAD)
+TARGET_FILE=${TARGET_FILE:?set TARGET_FILE to one changed file}
+
+{
+  printf 'Outside review mode: focused diff review\n'
+  printf 'Base branch: %s\nCurrent branch: %s\n\n' "$BASE_BRANCH" "$CURRENT_BRANCH"
+  printf 'git diff --stat %s...HEAD\n' "$BASE_BRANCH"
+  git diff --stat "$BASE_BRANCH"...HEAD
+  printf '\nChanged files:\n'
+  git diff --name-only "$BASE_BRANCH"...HEAD
+  printf '\nTarget file: %s\n' "$TARGET_FILE"
+  printf 'Bounded target diff (max 12000 bytes):\n'
+  git diff --unified=3 "$BASE_BRANCH"...HEAD -- "$TARGET_FILE" | \
+    head -c 12000
+  printf '\n\nQuestion: Identify the highest-signal correctness, security, data-loss, or maintainability risk in %s. Quote only the smallest relevant excerpt. If context is insufficient, answer INSUFFICIENT_CONTEXT.\n' "$TARGET_FILE"
+} >"$PROMPT_FILE"
+```
+
+#### Progress-aware review runtime
+
+Run one review through the typed `wp review run` owner. Skills must not embed
+subprocess supervision. The runtime consumes Claude's streaming JSON events,
+advances its idle clock only on monotonic semantic progress, and has no total
+wall-clock cutoff.
+
+The artifact root contains private runtime diagnostics, not a recorded
+transcript or committable approval evidence. Direct `wp review run` output is
+advisory. `wp_review_gate` is plan-only exact-version draft approval/auto-promotion;
+implementation/phase reviews use advisory `wp_review_run` and never mutate
+blueprint approval state. CLI delivery gates are MCP-unavailable compatibility only.
+
+```bash
+CLAUDE_REVIEW_MODEL=${CLAUDE_REVIEW_MODEL:-}
+CLAUDE_MODEL_ARGS=()
+if [ -n "$CLAUDE_REVIEW_MODEL" ]; then
+  CLAUDE_MODEL_ARGS=(--model "$CLAUDE_REVIEW_MODEL")
+fi
+CLAUDE_REVIEW_EFFORT=${CLAUDE_REVIEW_EFFORT:-medium}
+CLAUDE_REVIEW_IDLE_SECONDS=${CLAUDE_REVIEW_IDLE_SECONDS:-180}
+CLAUDE_REVIEW_ARTIFACT_ROOT=${CLAUDE_REVIEW_ARTIFACT_ROOT:-"$(pwd)/.webpresso/reviews"}
+CLAUDE_REVIEW_CODE=0
+wp review run \
+  --provider claude \
+  --prompt-file "$PROMPT_FILE" \
+  "${CLAUDE_MODEL_ARGS[@]}" \
+  --effort "$CLAUDE_REVIEW_EFFORT" \
+  --stage review \
+  --artifact-root "$CLAUDE_REVIEW_ARTIFACT_ROOT" \
+  --idle-seconds "$CLAUDE_REVIEW_IDLE_SECONDS"
+CLAUDE_REVIEW_CODE=$?
+```
+
+Treat `true-idle`, `protocol-unsupported`, provider failure, abort, spawn failure, or artifact failure as an unavailable advisory result. Never replace them with a static timeout, arbitrary byte-growth heartbeat, or buffered-output fallback.
+
+#### Invocation policy
+
+Run one provider review per invocation. Do not retry, fall back to another
+provider, or rotate accounts within the invocation. A new invocation requires
+an explicit diagnosis and caller decision. Do not fall back to an unbounded
+whole-PR prompt.
+
+Summarize findings with severity, evidence, model, artifact path, and whether you independently verified them.
+
+### Challenge
+
+Ask Claude to argue against the current plan: hidden assumptions, failure modes, missing tests, and simpler alternatives.
+
+### Consult
+
+Ask a focused repo question. Include only the necessary file paths and snippets; do not send secrets.

package/skills/codex/SKILL.md

@@ -0,0 +1,142 @@
+---
+name: codex
+description: "Codex CLI outside-voice wrapper for code review, plan challenge, or consultation from non-Codex hosts."
+license: MIT
+---
+
+# Codex outside voice
+
+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.
+
+## Primary path: the `wp_review_run` MCP tool
+
+When the webpresso MCP server is available, call `wp_review_run` exactly once instead of any bash block below. It is the same `wp review run` typed runtime, called in-process, and takes a `prompt` string without `--prompt-file` bookkeeping. Use the default review stage.
+
+```jsonc
+// wp_review_run MCP tool call
+{
+  "prompt": "<diff summary + what to look for>",
+  "provider": "codex",
+  // model, effort, artifactRoot, idleSeconds, and stage are optional and
+  // default the same way the `wp review run` CLI does. The default stage is
+  // review.
+}
+```
+
+Use the requested provider for this invocation. Do not retry, use provider fallback, or rotate accounts within the invocation. Never shell into a provider CLI when MCP is available; that bypasses typed artifact capture under `.webpresso/reviews`. The pretool guard hook redirects provider review launches to MCP.
+
+For long-running reviews, prefer the async MCP path: call `wp_review_run` with
+`"provider": "codex"` and `"background": true`, then poll `wp_review_wait`
+with the returned `runId`. Do not solve MCP transport limits by inflating
+synchronous review timeouts.
+
+The bash blocks in this skill (below) are the **MCP-unavailable fallback only** — use them when the webpresso MCP server itself is not reachable in the current host, not as a provider-fallback mechanism.
+
+## 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` (MCP) or `wp review run` (CLI fallback) over spawn/wait agent loops for review.
+- Keep prompts bounded; no whole-repo paste.
+
+## MCP-unavailable fallback (raw CLI)
+
+Everything from here down is the manual `wp review run` CLI path documented for hosts or sessions where the webpresso MCP server is not reachable. Prefer `wp_review_run` above whenever MCP is available.
+
+## MCP-unavailable fallback: auth check
+
+```bash
+if ! codex login status >/dev/null 2>&1; then
+  echo "CODEX_AUTH=missing: run codex login before using the codex outside-voice skill"
+  exit 1
+fi
+echo "CODEX_AUTH=ok"
+```
+
+## MCP-unavailable fallback: portable prompt file
+
+```bash
+PROMPT_FILE=$(mktemp -t wp-codex-review.XXXXXX)
+trap 'rm -f "$PROMPT_FILE"' EXIT
+```
+
+## Dashboard helper relation
+
+When called by `wp dash`, record the outside-voice lifecycle with
+`wp dash-helper-start --provider codex --role reviewer` and
+`wp dash-helper-complete --provider codex --role reviewer --outcome <completed|failed>`
+using the actual terminal outcome and artifact path.
+Standalone calls skip helper emission. Codex native subagent events are not
+parent-linked in the managed lifecycle; this unsupported coverage must stay
+explicit, and completion must never be inferred from text, PIDs, or
+timestamps.
+
+## Options
+
+Every mode runs through the `wp review run` runtime and honors these environment
+overrides. Set them inline, e.g.
+`CODEX_REVIEW_MODEL=gpt-5.6-sol CODEX_REVIEW_EFFORT=high /codex`.
+
+- `CODEX_REVIEW_MODEL` — the Codex model. Defaults to the `model = "..."` in the
+  active Codex config (`${CODEX_HOME:-~/.codex}/config.toml`); if neither the
+  environment nor config names a model, `wp review run` lets the Codex CLI choose
+  its own default. It MUST be a model the current login is provisioned for: ChatGPT-account
+  logins use the config's codenamed ids (e.g. `gpt-5.6-sol`) and reject a bare
+  `gpt-5.6`. When the user names a model ("review with 5.6-sol"), pass it here.
+- `CODEX_REVIEW_EFFORT` — reasoning effort, default `medium`. The review stage
+  accepts only `medium` or `high`; any other value is rejected.
+- `CODEX_REVIEW_IDLE_SECONDS` — idle timeout in seconds for the review stage,
+  default `180`.
+- `CODEX_REVIEW_ARTIFACT_ROOT` — directory for private runtime diagnostics,
+  default `<cwd>/.webpresso/reviews`. Never commit files from this directory or
+  cite them as approval evidence.
+
+Direct `wp review run` output is advisory. `wp_review_gate` is plan-only
+exact-version draft approval/auto-promotion; implementation/phase reviews use
+advisory `wp_review_run` and never mutate blueprint approval state. CLI delivery
+gates are MCP-unavailable compatibility only.
+
+## Modes
+
+### Review
+
+1. Capture the current branch, base branch, and `git diff --stat`.
+2. Write a concise prompt asking Codex to find correctness, security, data-loss, and maintainability risks.
+3. Run Codex through the typed review runtime in read-only mode:
+
+```bash
+# CODEX_REVIEW_MODEL / CODEX_REVIEW_EFFORT are overridable — see ## Options for
+# the full option list, valid values, and how to pick a login-supported model.
+CODEX_REVIEW_MODEL=${CODEX_REVIEW_MODEL:-}
+CODEX_MODEL_ARGS=()
+if [ -n "$CODEX_REVIEW_MODEL" ]; then
+  CODEX_MODEL_ARGS=(--model "$CODEX_REVIEW_MODEL")
+fi
+CODEX_REVIEW_EFFORT=${CODEX_REVIEW_EFFORT:-medium}
+case "$CODEX_REVIEW_EFFORT" in
+  medium|high) ;;
+  *) echo "CODEX_REVIEW_EFFORT must be one of: medium, high" >&2; exit 2 ;;
+esac
+CODEX_REVIEW_IDLE_SECONDS=${CODEX_REVIEW_IDLE_SECONDS:-180}
+CODEX_REVIEW_ARTIFACT_ROOT=${CODEX_REVIEW_ARTIFACT_ROOT:-"$(pwd)/.webpresso/reviews"}
+CODEX_REVIEW_CODE=0
+wp review run \
+  --provider codex \
+  --prompt-file "$PROMPT_FILE" \
+  "${CODEX_MODEL_ARGS[@]}" \
+  --effort "$CODEX_REVIEW_EFFORT" \
+  --stage review \
+  --artifact-root "$CODEX_REVIEW_ARTIFACT_ROOT" \
+  --idle-seconds "$CODEX_REVIEW_IDLE_SECONDS"
+CODEX_REVIEW_CODE=$?
+```
+
+4. Summarize findings with severity, evidence, and whether you independently verified them.
+
+### Challenge
+
+Ask Codex to argue against the current plan: hidden assumptions, failure modes, missing tests, and simpler alternatives.
+
+### Consult
+
+Ask a focused repo question. Include only the necessary file paths and snippets; do not send secrets.

package/skills/deep-interview/LICENSE.txt

@@ -0,0 +1,28 @@
+MIT License
+
+Copyright (c) 2026 Yeachan Heo
+
+Applies to the upstream deep-interview skill vendored from
+https://github.com/Yeachan-Heo/oh-my-codex at commit
+0e00a6ebdd12a6674f5a4735942940b9bdcdb8c0. The upstream repository declares
+the MIT license in its package.json and Cargo.toml at that commit without
+shipping a standalone LICENSE file; this file preserves the standard MIT
+copyright and permission notice for the vendored material.
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/skills/deep-interview/SKILL.md

@@ -0,0 +1,269 @@
+---
+type: skill
+slug: deep-interview
+title: Deep Interview
+status: active
+scope: repo
+applies_to: [agents]
+related: [ralplan, autopilot, deep-research]
+created: "2026-07-17"
+last_reviewed: "2026-07-17"
+name: deep-interview
+description: "Socratic requirements interview with ambiguity gating before planning or execution handoff."
+license: MIT
+upstream:
+  source: https://github.com/Yeachan-Heo/oh-my-codex/tree/0e00a6ebdd12a6674f5a4735942940b9bdcdb8c0/skills/deep-interview
+  last_synced: "2026-07-17"
+argument-hint: "[--quick|--standard|--deep] <idea or vague description>"
+---
+
+<Purpose>
+Deep Interview is an intent-first Socratic clarification loop that runs before planning or implementation. It turns vague ideas into execution-ready requirements by asking targeted questions about why the user wants a change, how far it should go, what should stay out of scope, and what the agent may decide without confirmation. It is a requirements mode: it produces a spec and hands off — it does NOT implement.
+</Purpose>
+
+<Use_When>
+
+- The request is broad, ambiguous, or missing concrete acceptance criteria
+- The user says "deep interview", "interview me", "ask me everything", or "don't assume"
+- You want to avoid misaligned implementation from underspecified requirements
+- You need a requirements artifact before handing off to `ralplan`, `autopilot`, `ultragoal`, `team`, or a new blueprint
+  </Use_When>
+
+<Do_Not_Use_When>
+
+- The request already has concrete file/symbol targets and clear acceptance criteria
+- The user explicitly asks to skip planning/interview and execute immediately
+- The user wants a technology/tradeoff investigation (use `deep-research`)
+- A complete blueprint/plan already exists and execution should start
+  </Do_Not_Use_When>
+
+<Why_This_Exists>
+Execution quality is usually bottlenecked by intent clarity, not just missing implementation detail. A single expansion pass often misses why the user wants a change, where scope should stop, which tradeoffs are unacceptable, and which decisions still require user approval. This workflow applies Socratic pressure plus quantitative ambiguity scoring so downstream planning begins with an explicit, testable, intent-aligned spec.
+</Why_This_Exists>
+
+<Depth_Profiles>
+
+- **Quick (`--quick`)**: fast pre-plan pass; target ambiguity `<= 0.30`; max 5 rounds
+- **Standard (`--standard`, default)**: full requirement interview; target `<= 0.20`; max 12 rounds
+- **Deep (`--deep`)**: high-rigor exploration; target `<= 0.15`; max 20 rounds
+
+Max rounds is a hard cap, not a target. Do not continue only to reach a round count. Extra rigor does not override the active threshold. If no flag is provided, use **Standard**.
+</Depth_Profiles>
+
+<Execution_Policy>
+
+- Ask ONE question per round. Never batch multiple interview rounds into one prompt.
+- Ask about intent and boundaries before implementation detail.
+- Target the weakest clarity dimension each round, after applying the stage-priority rules below.
+- Treat every answer as a claim to pressure-test: the next question should usually demand evidence or an example, expose a hidden assumption, force a tradeoff or boundary, or reframe root cause vs symptom.
+- Do not rotate to a new dimension just for coverage when the current answer is still vague. Stay on the thread until it is one layer deeper, one assumption clearer, or one boundary tighter.
+- Before crystallizing, complete at least one explicit pressure pass that revisits an earlier answer with a deeper, assumption- or tradeoff-focused follow-up.
+- Gather codebase facts via local search tools, `wp_session_*` retrieval, and read-only repo inspection before asking the user about internals.
+- Always run a preflight context intake before the first question.
+- For brownfield work, preflight must ground in docs before user-facing questions: inspect applicable `AGENTS.md`/`CLAUDE.md`, README/getting-started docs, relevant `docs/` contracts/plans/ADRs, existing blueprints under `blueprints/`, and any project glossary such as `UBIQUITOUS_LANGUAGE.md` when present.
+- Treat repo language as evidence, not authority: if the user uses a fuzzy, overloaded, or conflicting term, surface the specific doc/code wording and ask which meaning should govern.
+- Cross-check user claims about current behavior against code or documented contracts. If docs and code disagree, ask a confirmation question that names both sources instead of silently choosing one.
+- Use scenario-based edge-case grilling when relationships, boundaries, or handoff behavior are unclear: invent one concrete scenario that stresses the ambiguous boundary, then ask one focused question about the expected outcome.
+- Reduce user effort: ask only the highest-leverage unresolved question, and never ask the user for codebase facts you can discover directly.
+- For brownfield work, prefer evidence-backed confirmation questions such as "I found X in Y. Should this change follow that pattern?"
+- Route facts before judgment: before each user-facing round, classify whether the needed information is a discoverable fact, a fact needing confirmation, or a human decision. The interview is with the human for judgment, not for facts the agent can inspect.
+- When unresolved ambiguity depends on current external best practices, upstream guidance, standards, or version-aware behavior, use `best-practice-research` as the bounded evidence wrapper before crystallizing.
+- Auto-confirm only descriptive facts. If a finding implies what the feature should do, which pattern to follow, which tradeoff to accept, or what stays in/out of scope, route that decision to the user.
+- Re-score ambiguity after each answer and show progress transparently.
+- Once ambiguity is at or below the active threshold, stop ordinary questioning. Run the closure audit: crystallize/hand off when the readiness gates pass; otherwise ask only the final closure question needed to satisfy a named gate.
+- Do not crystallize or hand off while `Non-goals` or `Decision Boundaries` remain unresolved, even if the weighted threshold is met.
+- Do not hand off to execution while ambiguity remains above threshold unless the user explicitly opts to proceed with a warning.
+- Treat early exit as a safety valve, not the default success path.
+  </Execution_Policy>
+
+<Steps>
+
+## Phase 0: Preflight Context Intake
+
+1. Parse `{{ARGUMENTS}}` and derive a short kebab-case task slug.
+2. Attempt to load the latest relevant context for the slug from session memory via the `wp_session_search`/`wp_session_retrieve` MCP tools.
+3. If the provided initial context (or loaded snapshot) is too large for safe prompt use, the first round must ask for a concise prompt-safe summary before scoring ambiguity or any downstream handoff. This gate is blocking: preserve goals, constraints, success criteria, non-goals, decision boundaries, and references to the full source documents.
+4. If no snapshot exists, create a minimum snapshot with: task statement, desired outcome, stated solution, probable intent hypothesis, known facts/evidence, constraints, unknowns/open questions, decision-boundary unknowns, likely codebase touchpoints, repo docs/rules inspected, terminology/doc-code conflicts found.
+5. For brownfield tasks, inspect the applicable documentation/rule surface before the first user-facing round. Prefer exact, nearby sources: governing `AGENTS.md`/`CLAUDE.md`, README/getting-started docs, relevant `docs/` contracts/plans/ADRs, existing blueprints, and project glossary/context files when present.
+6. Capture the snapshot into session memory via `wp_session_capture` (tagged with the slug) and reference it in the interview state.
+
+## Phase 1: Initialize
+
+1. Parse `{{ARGUMENTS}}` and the depth profile (`--quick|--standard|--deep`).
+2. Detect project context: use local search tools and read-only repo inspection to classify **brownfield** (existing codebase target) vs **greenfield**; for brownfield, collect relevant context before questioning.
+3. Persist a lightweight resumable interview state to session memory via `wp_session_capture` (interview id, profile, type, initial idea, rounds, current ambiguity, threshold, max rounds, challenge modes used, current stage/focus, context snapshot reference), so a later session can resume via `wp_session_search`/`wp_session_restore`.
+4. Announce kickoff with the profile, threshold, and current ambiguity.
+
+## Phase 2: Socratic Interview Loop
+
+Repeat until ambiguity `<= threshold`, the pressure pass is complete, and the readiness gates are explicit — or the user exits with warning or max rounds are reached. This is a stop condition: below threshold, do not open a new ordinary interview branch.
+
+### 2a) Generate next question
+
+If the initial context is oversized and no prompt-safe summary has been recorded, the next question must be only a summary request. Do not score ambiguity or hand off until that summary is captured.
+
+Use the original idea, prior Q&A rounds, current dimension scores, brownfield context, doc/terminology grounding notes, and any activated challenge mode (Phase 3).
+
+Target the lowest-scoring dimension, but respect stage priority:
+
+- **Stage 1 — Intent-first:** Intent, Outcome, Scope, Non-goals, Decision Boundaries
+- **Stage 2 — Feasibility:** Constraints, Success Criteria
+- **Stage 3 — Brownfield grounding:** Context Clarity (brownfield only)
+
+Follow-up pressure ladder after each answer:
+
+1. Ask for a concrete example, counterexample, or evidence signal behind the latest claim.
+2. Probe the hidden assumption, dependency, or belief that makes the claim true.
+3. Force a boundary or tradeoff: what would you explicitly not do, defer, or reject?
+4. Challenge fuzzy or conflicting terms against the repo's documented language and current behavior.
+5. Stress-test the boundary with one concrete scenario when a relationship or handoff remains ambiguous.
+6. If the answer still describes symptoms, reframe toward root cause before moving on.
+
+Prefer staying on the highest-leverage thread across multiple rounds. Breadth without pressure is not progress.
+
+Maintain a **Breadth Ledger** across independent tracks (scope, constraints, outputs, verification, brownfield integration, plus any user-mentioned deliverable). The ledger is a guard, not a rotation rule: stay deep on the current thread until it is pressure-tested, then zoom out only when another material track remains unresolved and would change execution.
+
+Maintain a **Docs/Terminology Ledger** for brownfield interviews: repo docs/rules inspected (with paths), canonical terms already in use, user terms that conflict with docs or code, and doc/code mismatches that require a human decision before implementation.
+
+Detailed dimensions:
+
+- Intent Clarity — why the user wants this
+- Outcome Clarity — what end state they want
+- Scope Clarity — how far the change should go
+- Constraint Clarity — technical or business limits that must hold
+- Success Criteria Clarity — how completion will be judged
+- Context Clarity — existing codebase understanding (brownfield only)
+
+`Non-goals` and `Decision Boundaries` are mandatory readiness gates. Ask about them early and keep revisiting them until they are explicit.
+
+### 2b) Ask the question
+
+Ask exactly one question per round using the host's native structured-question tool (e.g. `AskUserQuestion`) when available; otherwise ask one concise plain-text question and wait for the answer. Present:
+
+```
+Round {n} | Target: {weakest_dimension} | Ambiguity: {score}%
+
+{question}
+```
+
+Question-shape guidance:
+
+- Deep Interview is Socratic — one focused round at a time. Never combine multiple rounds into one prompt.
+- Use a **single-answerable** round when exactly one answer should drive the next branch, the options are mutually exclusive, or selecting more than one would blur the decision (e.g. handoff lane selection, choosing the primary failure mode, confirming which competing interpretation is correct).
+- Use a **multi-answerable** round when multiple options may all be true at once and you need a bounded set of coexisting constraints, non-goals, risks, or acceptance checks in one round (e.g. all out-of-scope items, all success metrics that must hold, all deployment constraints that apply).
+- If one selected option would immediately require a follow-up to disambiguate the others, prefer a single-answerable round now and ask the follow-up next. Do not hide a branching tree inside one overloaded multi-select.
+- Keep options bounded and concrete. Only leave an "other" escape hatch when the interview genuinely needs one user-supplied option that cannot be enumerated in advance.
+
+### 2c) Score ambiguity
+
+Score each weighted dimension in `[0.0, 1.0]` with justification and gap.
+
+Greenfield: `ambiguity = 1 - (intent × 0.30 + outcome × 0.25 + scope × 0.20 + constraints × 0.15 + success × 0.10)`
+
+Brownfield: `ambiguity = 1 - (intent × 0.25 + outcome × 0.20 + scope × 0.20 + constraints × 0.15 + success × 0.10 + context × 0.10)`
+
+Readiness gate:
+
+- `Non-goals` must be explicit.
+- `Decision Boundaries` must be explicit.
+- A pressure pass must be complete: at least one earlier answer revisited with an evidence, assumption, or tradeoff follow-up.
+- A closure audit must pass: another question would change execution materially, not merely polish wording or chase a narrow edge case.
+- If a gate is unresolved or the pressure pass is incomplete, continue below threshold only with a final closure question that names the unresolved gate.
+- Treat a low score as permission to audit closure, not to keep drilling. If remaining uncertainty would not change implementation, crystallize instead of opening a new branch.
+
+### 2d) Report progress
+
+Show the weighted breakdown table, readiness-gate status (`Non-goals`, `Decision Boundaries`), and the next focus dimension.
+
+### 2e) Persist state
+
+Append the round result and updated scores to the slug-tagged interview state in session memory (`wp_session_capture`).
+
+### 2f) Round controls
+
+- Do not offer early exit before the first explicit assumption probe and one persistent follow-up have happened.
+- Apply a **Dialectic Rhythm Guard**: after 3 consecutive fact/confirmation answers, the next material round must solicit direct human judgment — unless the closure audit says the interview is ready to crystallize.
+- Round 4+: allow explicit early exit with a risk warning.
+- Soft warning at the profile midpoint.
+- Hard cap at the profile max rounds; never treat this cap as a desired interview length.
+
+## Phase 3: Challenge Modes (assumption stress tests)
+
+Use each mode once when applicable — normal escalation tools, not rare rescue moves:
+
+- **Contrarian** (round 2+ or immediately when an answer rests on an untested assumption): challenge core assumptions.
+- **Terminologist** (brownfield, when a key term is fuzzy, overloaded, or conflicts with repo docs/code): force a canonical meaning against existing project language before implementation.
+- **Simplifier** (round 4+ or when scope expands faster than outcome clarity): probe minimal viable scope.
+- **Ontologist** (round 5+ and ambiguity > 0.25, or when the user keeps describing symptoms): ask for essence-level reframing.
+
+Track used modes in state to prevent repetition.
+
+## Phase 4: Crystallize Artifacts
+
+When the threshold is met (or the user exits with warning / hard cap):
+
+1. Create or update the versioned draft that owns this task with `wp_blueprint_put`, yielding `blueprints/draft/{slug}/`. In this repo, deep interviews exist to produce better blueprints before implementation; carry the returned `bpv1:` version through every replacement.
+2. Write the interview transcript summary to `blueprints/draft/{slug}/interview.md`.
+3. Fold the execution-ready spec into `blueprints/draft/{slug}/_overview.md` (intent, scope, non-goals, decision boundaries, constraints, acceptance criteria), and capture a copy of the final spec + scores into session memory via `wp_session_capture`.
+
+The spec should include: metadata (profile, rounds, final ambiguity, threshold, context type); context snapshot reference; prompt-safe initial-context summary when oversized context was provided, plus references to the full sources; the clarity breakdown table; Intent (why); Desired Outcome; In-Scope; Out-of-Scope / Non-goals; Decision Boundaries (what the agent may decide without confirmation); Constraints; testable acceptance criteria (prefer repo verification surfaces — `wp test`, `wp typecheck`, `wp audit` — over manual checks); assumptions exposed and their resolutions; pressure-pass findings (which answer was revisited and what changed); brownfield evidence-vs-inference notes; the Docs/Terminology Ledger; scenario/edge-case findings that shaped scope or acceptance; and the full or condensed transcript.
+
+Durable docs, glossary, or ADR updates are opt-in and public-safe only: recommend them in the handoff summary, but do not auto-create or dump public docs from interview transcripts unless the user explicitly chooses that as in-scope.
+
+## Phase 5: Execution Bridge
+
+Present execution options after artifact generation using explicit handoff contracts. Treat the deep-interview spec as the current requirements source of truth and preserve intent, non-goals, decision boundaries, acceptance criteria, docs/terminology grounding, and any residual-risk warnings across the handoff.
+
+- **`ralplan`** — when architecture/test-shape review is still needed. Consumer treats the spec as the requirements source of truth and refines architecture/feasibility around the clarified intent instead of re-interviewing.
+- **`autopilot`** — when the spec is already strong enough for direct planning plus execution. Consumer uses the spec as the clarified execution brief with the non-goals and acceptance criteria as binding context.
+- **`ultragoal`** — when the clarified work should become durable, sequentially tracked goal-mode work.
+- **`team`** — when the task is large, multi-lane, or blocker-sensitive enough to justify coordinated parallel execution.
+- **Blueprint lifecycle** — refine with `wp_blueprint_put`, review the exact version with `wp_review_gate`, and inspect the auto-promoted result with `wp_blueprint_get` when work should enter planned execution directly.
+- **Refine further** — re-enter the loop to resolve the highest-leverage remaining uncertainty when residual ambiguity is still too high or an early-exit/above-threshold warning indicates too much risk to proceed cleanly.
+
+For research-shaped requests (a research question, evaluator-backed analysis, or reference gathering), hand off to `autoresearch` after the interview converges on a validator-ready mission; keep the explicit `refine further` vs `launch` boundary and do not launch until the user confirms.
+
+**Residual-Risk Rule:** if the interview ended via early exit, hard cap, or above-threshold proceed-with-warning, explicitly preserve that residual-risk state in the handoff so the downstream skill knows it inherited a partially clarified brief.
+
+**IMPORTANT:** Deep Interview is a requirements mode. On handoff, invoke the selected skill using the contract above. **Do NOT implement directly** inside deep-interview.
+
+</Steps>
+
+<Tool_Usage>
+
+- Use local search tools, `wp_session_*` retrieval, and read-only repo inspection for codebase fact gathering.
+- Use the host's native structured-question tool (e.g. `AskUserQuestion`) for each round when available; otherwise ask one concise plain-text question and wait.
+- Keep context snapshots and resumable interview state in session memory via the `wp_session_*` MCP tools, tagged with the task slug.
+- Read applicable repo docs/rules/context during preflight; write durable docs/glossary/ADR updates only when the user explicitly opts in and the content is public-safe.
+- Land transcript artifacts in the active task's blueprint folder; create/update `_overview.md` only through `wp_blueprint_put`.
+- Use `best-practice-research` when unresolved ambiguity depends on current external/upstream guidance.
+  </Tool_Usage>
+
+<Escalation_And_Stop_Conditions>
+
+- User says stop/cancel/abort — persist state and stop.
+- Ambiguity stalls for 3 rounds (± 0.05) — force Ontologist mode once.
+- Max rounds reached — proceed with an explicit residual-risk warning.
+- All dimensions `>= 0.9` — allow early crystallization even before max rounds.
+  </Escalation_And_Stop_Conditions>
+
+<Final_Checklist>
+
+- [ ] Preflight context snapshot captured to session memory (`wp_session_capture`, slug-tagged)
+- [ ] Oversized initial context, if present, has a prompt-safe summary before scoring or handoff
+- [ ] Ambiguity score shown each round
+- [ ] Intent-first stage priority used before implementation detail
+- [ ] Weakest-dimension targeting used within the active stage
+- [ ] At least one explicit assumption probe before crystallization
+- [ ] At least one persistent follow-up / pressure pass deepened a prior answer
+- [ ] Challenge modes triggered at thresholds (when applicable)
+- [ ] `Non-goals` and `Decision Boundaries` explicit before handoff
+- [ ] Transcript written to `blueprints/draft/{slug}/interview.md`
+- [ ] Spec folded into `blueprints/draft/{slug}/_overview.md` through `wp_blueprint_put`
+- [ ] Brownfield questions use evidence-backed confirmation and doc grounding when applicable
+- [ ] Fuzzy/conflicting terminology challenged against repo language when applicable
+- [ ] Handoff options provided (`ralplan`, `autopilot`, `ultragoal`, `team`, blueprint lifecycle)
+- [ ] No direct implementation performed in this mode
+      </Final_Checklist>
+
+Task: {{ARGUMENTS}}