@webpresso/claude-plugin 3.1.19 → 3.1.20

package/.claude-plugin/marketplace.json

@@ -6,7 +6,7 @@
   },
   "metadata": {
     "description": "Webpresso agent-kit Claude Code plugin: blueprints, skills, hooks, MCP server",
-    "version": "3.1.19"
+    "version": "3.1.20"
   },
   "plugins": [
     {
@@ -14,19 +14,11 @@
       "source": "./",
       "description": "Webpresso agent-kit: blueprints, skills, lore commit protocol, tech-debt lifecycle",
       "category": "development",
-      "keywords": [
-        "agent",
-        "blueprint",
-        "claude-code",
-        "skills",
-        "mcp"
-      ],
+      "keywords": ["agent", "blueprint", "claude-code", "skills", "mcp"],
       "mcpServers": {
         "webpresso": {
           "command": "${CLAUDE_PLUGIN_ROOT}/bin/wp",
-          "args": [
-            "mcp"
-          ],
+          "args": ["mcp"],
           "env": {
             "WP_SKIP_UPDATE_CHECK": "1"
           }
@@ -34,5 +26,5 @@
       }
     }
   ],
-  "version": "3.1.19"
-}
+  "version": "3.1.20"
+}

package/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "agent-kit",
-  "version": "3.1.19",
+  "version": "3.1.20",
   "description": "Webpresso agent-kit: blueprints, skills, lore commit protocol, tech-debt lifecycle",
   "author": {
     "name": "Webpresso",
@@ -11,12 +11,10 @@
   "mcpServers": {
     "webpresso": {
       "command": "${CLAUDE_PLUGIN_ROOT}/bin/wp",
-      "args": [
-        "mcp"
-      ],
+      "args": ["mcp"],
       "env": {
         "WP_SKIP_UPDATE_CHECK": "1"
       }
     }
   }
-}
+}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@webpresso/claude-plugin",
-  "version": "3.1.19",
+  "version": "3.1.20",
   "private": false,
   "description": "Claude Code plugin adapter for Webpresso agent-kit skills, commands, and MCP runtime.",
   "homepage": "https://github.com/webpresso/agent-kit#readme",

package/plugin-skill-ownership.json

@@ -2,7 +2,7 @@
   "schemaVersion": 1,
   "host": "claude",
   "packageName": "@webpresso/claude-plugin",
-  "packageVersion": "3.1.19",
+  "packageVersion": "3.1.20",
   "runtimeDirs": [".claude/skills"],
   "skills": {
     "ai-deslop": {
@@ -15,17 +15,20 @@
       "digest": "sha256:b4d51cd53beb4a3271827172dfbd0b1d27bd58761ca07a35d49a5d6324b87fdf"
     },
     "best-practice-research": {
-      "digest": "sha256:b0d355c7f4afe9c38be83e293788bf582bea068c1db2fa5c45400441e315735d"
+      "digest": "sha256:6d26b524d206067c7305da8a9334270f2525e4323aa3faa56ef02679e4d61849"
     },
     "browse": {
       "digest": "sha256:21fd24862e7f7c8a1feadea6bc376492b136b99fc381cf1b8927c9db80615431"
     },
     "claude": {
-      "digest": "sha256:2af483ef80c5e0cf3d6d3da94d54b5bd1e9cecc9b2bd05e085499c2745c2c238"
+      "digest": "sha256:dec5cc89c31485bab6defea919c22e9a9c50c530d8fc4ef4f5be5080b5d91b75"
     },
     "codex": {
       "digest": "sha256:98187c2845b5cd88ba9eb9f682d16fec648932a084b3d1cebd066945b1fb6fdf"
     },
+    "deep-interview": {
+      "digest": "sha256:e80d7e12e486397103108bb473e98e8e8656519770fa20701f8b3e9e66991939"
+    },
     "deep-research": {
       "digest": "sha256:01dafd194066a2936db0b437fd5c3beef6d7ff82478d0d995393093d89496f18"
     },

package/skills/best-practice-research/SKILL.md

@@ -6,7 +6,7 @@ argument-hint: "<technology|decision|practice question>"
 
 # Best-Practice Research
 
-Use this skill when a task depends on current external best practices, version-aware guidance, standards, official recommendations, or upstream behavior. This is a workflow wrapper: it routes evidence gathering and synthesis; it is not a new research authority and it does not replace `researcher`.
+Use this skill when a task depends on current external best practices, version-aware guidance, standards, official recommendations, or upstream behavior. This is a workflow wrapper: it routes evidence gathering and synthesis; it is not a new research authority and it does not replace the `deep-research` skill.
 
 ## Purpose
 
@@ -15,21 +15,21 @@ Produce a cited, reusable best-practice answer or handoff that separates current
 ## Activate When
 
 - The user asks for best practices, recommended approach, current guidance, official recommendations, standards, or version-aware external behavior.
-- `$ralplan`, `$deep-interview`, `$team`, or another workflow needs current external evidence before planning or execution can be correct.
+- `$ralplan`, `$team`, or another workflow needs current external evidence before planning or execution can be correct.
 - The task involves an already chosen technology and needs authoritative usage guidance, migration notes, API behavior, lifecycle rules, or current safety guidance.
 
 ## Do Not Activate When
 
 - The answer is fully repo-local; use `explore` for codebase facts.
-- The main question is whether to adopt, replace, upgrade, or compare dependencies; use `dependency-expert`.
-- The user only needs implementation against already-grounded requirements; use `executor`, `$ralph`, or `$team` as appropriate.
+- The main question is whether to adopt, replace, upgrade, or compare dependencies — that decision is out of scope; inform it with evidence but return the choice to the caller.
+- The user only needs implementation against already-grounded requirements; hand off to the caller's execution workflow (`$team` or `$ralplan`) as appropriate.
 - The task can be answered from stable local project conventions without current external lookup.
 
 ## Specialist Routing
 
 1. Use `explore` first for brownfield facts: current code usage, local constraints, versions, config, and integration points.
-2. Use `researcher` for official/upstream docs, release notes, standards, migration guides, source-backed examples, and current best-practice evidence for an already chosen technology.
-3. Use `dependency-expert` only for adoption/upgrade/replacement/comparison decisions.
+2. Gather official/upstream docs, release notes, standards, migration guides, and source-backed evidence yourself with web search and doc fetches; escalate to the `deep-research` skill for exhaustive multi-source research on an already chosen technology.
+3. Adoption / upgrade / replacement / comparison decisions are out of scope: surface the evidence, but return the decision to the caller.
 4. Return to the caller with explicit evidence, uncertainty, and any implementation handoff constraints.
 
 ## Source-Quality Rules
@@ -45,7 +45,7 @@ Produce a cited, reusable best-practice answer or handoff that separates current
 
 1. Classify the question: conceptual best practice, implementation guidance, migration/version guidance, standards/compliance guidance, or mixed local + external guidance.
 2. Gather repo-local facts with `explore` when local usage or constraints affect the answer.
-3. Gather external evidence with `researcher` when current or version-aware practice affects correctness.
+3. Gather external evidence with web search and official-doc fetches (escalate to the `deep-research` skill for depth) when current or version-aware practice affects correctness.
 4. Synthesize a concise answer with source quality, version/date context, caveats, and an implementation or planning handoff.
 5. Stop when the answer is grounded enough for the caller; otherwise report the exact blocker or specialist handoff needed.
 

package/skills/claude/SKILL.md

@@ -57,7 +57,7 @@ Claude's managed native subagent lifecycle does not provide a reliable parent-li
 
 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:** default to the moving `opus` alias via `CLAUDE_REVIEW_MODEL=${CLAUDE_REVIEW_MODEL:-opus}`. Never use `fable` for Claude outside-voice review. Any review used as blueprint approval evidence MUST run with Claude Opus and record `"model": "opus"`.
+**Model policy:** default to the moving `opus` alias via `CLAUDE_REVIEW_MODEL=${CLAUDE_REVIEW_MODEL:-opus}`. A caller may explicitly override `CLAUDE_REVIEW_MODEL` (for example to `fable` for a lighter advisory pass); honor the requested model. However, any review used as blueprint **promotion or completion** approval evidence (draft→planned, or planned/in-progress→completed) MUST run with Claude Opus and record `"model": "opus"`.
 
 #### Bounded prompt payload
 

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 draft blueprint that owns this task: `wp blueprint new "<clarified goal>" --complexity <XS|S|M|L|XL>` when none exists, yielding `blueprints/draft/{slug}/`. In this repo, deep interviews exist to produce better blueprints before implementation — the blueprint folder is where the interview output lands.
+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 the seeded draft under `blueprints/draft/{slug}/`, then advance it through the normal lifecycle (`wp blueprint promote {slug} planned` once the promotion gate passes, `wp blueprint start {slug}` for the owner worktree) when the 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 and spec artifacts in the active task's blueprint folder (`blueprints/draft/{slug}/`), created via `wp blueprint new` when missing.
+- 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` (blueprint created via `wp blueprint new` if missing)
+- [ ] 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}}