@webpresso/plugin-opencode 0.0.4

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}}

package/skills/deep-research/SKILL.md

@@ -0,0 +1,258 @@
+---
+type: skill
+slug: deep-research
+title: Deep Research
+status: active
+scope: repo
+applies_to: [agents]
+related: []
+created: "2026-05-07"
+last_reviewed: "2026-05-07"
+name: deep-research
+description: "Deep web research with dated credible sources, pro/con synthesis, and project-alignment notes."
+argument-hint: "<subject or question to research>"
+---
+
+<Purpose>
+Deep Research is a multi-phase web research workflow that produces a balanced, citation-backed analysis of a subject. It collects both positive and negative sentiments from credible sources, evaluates alignment with the project's vision and tech stack, identifies 2026 state-of-the-art best practices, and logs the result to `docs/research/` with a date-prefixed filename.
+</Purpose>
+
+<Use_When>
+
+- Evaluating a technology, library, pattern, or product direction
+- Comparing alternatives before making an architectural or product decision
+- The user says "research", "deep research", "investigate", or "what does the community think about"
+- You need a balanced view of trade-offs before recommending something
+  </Use_When>
+
+<Do_Not_Use_When>
+
+- The user wants a quick factual lookup (use WebSearch directly)
+- The user wants codebase exploration (use explore)
+- The user wants a requirements interview (use deep-interview)
+- The answer is already well-established and non-controversial
+  </Do_Not_Use_When>
+
+<Output_Contract>
+A single markdown file written to:
+
+```
+docs/research/{YYYY-MM-DD}-{slug}.md
+```
+
+Where `{YYYY-MM-DD}` is today's date and `{slug}` is a kebab-case summary of the subject.
+
+The file MUST have this frontmatter and structure (see Phase 5 for full template).
+</Output_Contract>
+
+<Steps>
+
+## Phase 0: Scope and Context Load
+
+1. Parse `{{ARGUMENTS}}` into a research subject and any qualifiers (e.g., "for our use case", "vs X").
+2. Derive a short kebab-case slug for the filename.
+3. Read `docs/research/product/VISION.md` (or the project's equivalent — check `docs/` for a vision doc) to load the current vision context. Skip if not present.
+4. Identify the relevant tech stack context by reading project config files (e.g., `package.json` workspaces, `tsconfig.json`, key dependencies) — keep this lightweight, just enough to judge alignment.
+5. Announce the research plan to the user:
+   - Subject
+   - Key questions to investigate
+   - Output path
+
+## Phase 1: Broad Discovery (parallel)
+
+Run **5-8 parallel WebSearch queries** covering different angles:
+
+1. **Overview**: `"{subject} 2026 overview best practices"`
+2. **Positive sentiment**: `"{subject} benefits advantages why use 2026"`
+3. **Negative sentiment / criticism**: `"{subject} problems criticism drawbacks 2026"`
+4. **Community opinion**: `"{subject} reddit hacker news experience production 2026"`
+5. **Comparison / alternatives**: `"{subject} vs alternatives comparison 2026"`
+6. **State of the art**: `"{subject} state of the art latest 2026"`
+7. **(If applicable)** Stack-specific: `"{subject} TypeScript Cloudflare Workers React 2026"`
+8. **(If applicable)** Domain-specific query based on the project's problem space
+
+For each search, record:
+
+- Source URL
+- Source type (docs, blog, forum, official, academic)
+- Key claims or data points
+- Sentiment direction (positive / negative / neutral)
+
+## Phase 2: Deep Dive (sequential, selective)
+
+From Phase 1 results, identify the **5-10 most credible and information-dense sources**.
+
+Use `WebFetch` on each to extract deeper detail. Prioritize:
+
+- Official documentation or announcements
+- Production experience reports (postmortems, migration stories)
+- Benchmark data or technical comparisons
+- Strong critical takes with specific evidence
+
+For each fetched source, extract:
+
+- Specific claims with evidence
+- Sentiment and strength (strong positive, mild positive, neutral, mild negative, strong negative)
+- Credibility assessment (official docs > production experience > blog opinion > forum anecdote)
+
+## Phase 3: Triangulate and Score
+
+1. **Cluster findings** into themes (e.g., "developer experience", "performance", "ecosystem maturity", "production readiness").
+2. **Cross-reference claims**: if only one source makes a claim, flag it as unverified. Claims supported by 2+ independent sources get higher weight.
+3. **Score source credibility** using:
+   - Official docs / specs: high
+   - Production postmortems with data: high
+   - Respected engineering blogs: medium-high
+   - Community forums (HN, Reddit) with detail: medium
+   - Marketing material / vendor blogs: low (note bias)
+   - Undated or anonymous content: very low
+4. **Identify gaps**: what questions remain unanswered? If critical gaps exist, run 1-2 additional targeted searches.
+
+## Phase 4: Vision and Stack Alignment Analysis
+
+Using the project's vision from Phase 0 and the research findings:
+
+1. **Vision alignment**: How does this subject relate to the project's stated mission? Does it help or hinder current priorities?
+2. **Tech stack fit**: How well does this integrate with the existing stack (read `package.json`, key deps, framework choices)? What's the integration cost?
+3. **Trade-off assessment**: Given the project's current stage, what are the most relevant trade-offs?
+4. **Recommendation**: Based on the evidence, what's the suggested path? Be explicit about confidence level.
+
+## Phase 5: Write Report
+
+Write the report to `docs/research/{YYYY-MM-DD}-{slug}.md` using this template:
+
+```markdown
+---
+type: research
+title: "{Title}"
+subject: "{subject}"
+date: { YYYY-MM-DD }
+confidence: { high|medium|low }
+verdict: { adopt|trial|assess|hold|reject }
+---
+
+# {Title}
+
+> One-line summary of the finding.
+
+## TL;DR
+
+3-5 bullet executive summary covering: what it is, key finding, recommendation.
+
+## What This Is
+
+Brief neutral description of the subject being researched.
+
+## State of the Art (2026)
+
+Current best practices, latest developments, where the ecosystem stands today.
+Cite sources inline as [Source Name](url).
+
+## Positive Signals
+
+Evidence-backed reasons in favor. Group by theme.
+Each point should cite its source and note credibility level.
+
+### {Theme 1}
+
+- ...
+
+### {Theme 2}
+
+- ...
+
+## Negative Signals
+
+Evidence-backed criticism and risks. Group by theme.
+Each point should cite its source and note credibility level.
+
+### {Theme 1}
+
+- ...
+
+### {Theme 2}
+
+- ...
+
+## Community Sentiment
+
+What practitioners actually say. Include direct quotes where available.
+Note the balance: if sentiment skews one way, say so explicitly.
+
+## Project Alignment
+
+### Vision Fit
+
+How this relates to the project's current goals.
+
+### Tech Stack Fit
+
+Integration with the project's stack (from `package.json`, framework configs).
+
+### Trade-offs for Current Stage
+
+What matters most given where the project is now.
+
+## Recommendation
+
+Clear recommendation with confidence level and reasoning.
+Include conditions under which the recommendation would change.
+
+## Sources
+
+Numbered list of all sources used, with:
+
+- [N] [Title](url) — type, credibility, sentiment direction
+```
+
+## Phase 6: Present Summary
+
+After writing the file, present to the user:
+
+1. The output file path
+2. The verdict and confidence
+3. A 3-line summary of the key finding
+4. Any critical gaps or caveats
+
+</Steps>
+
+<Quality_Gates>
+
+- Minimum 8 distinct sources cited
+- At least 2 sources per major claim
+- Both positive AND negative signals sections must be substantive (not token)
+- Sources section must include credibility and sentiment annotations
+- Vision alignment section must reference specific project goals (not generic)
+- All inline citations must be clickable links
+- Frontmatter must include confidence and verdict fields
+  </Quality_Gates>
+
+<Verdict_Scale>
+
+- **adopt**: Strong evidence, clear fit, community consensus positive. Use it.
+- **trial**: Promising evidence, worth a bounded experiment. Try it in a limited scope.
+- **assess**: Mixed signals or insufficient evidence. Research more before committing.
+- **hold**: Significant concerns or poor fit. Don't invest now, revisit later.
+- **reject**: Clear evidence against. Don't use this.
+  </Verdict_Scale>
+
+<Tool_Usage>
+
+- `WebSearch` for broad discovery (Phase 1) and gap-filling (Phase 3)
+- `WebFetch` for deep source extraction (Phase 2)
+- `Read` for loading vision and tech stack context (Phase 0)
+- `Write` for the final report (Phase 5)
+- `Agent` with `subagent_type=Explore` if codebase context is needed for alignment analysis
+- Use parallel tool calls wherever searches are independent
+  </Tool_Usage>
+
+<Common_Mistakes>
+
+- Writing a report that's all positive or all negative — always find both sides
+- Citing marketing material as if it were neutral evidence — flag vendor bias
+- Making alignment claims without reading the actual vision doc
+- Using stale search results — always include "2026" in queries
+- Writing the report before triangulating — don't just concatenate search results
+  </Common_Mistakes>
+
+Task: {{ARGUMENTS}}

package/skills/delivery-program/SKILL.md

@@ -0,0 +1,57 @@
+---
+type: skill
+slug: delivery-program
+title: Delivery Program
+status: active
+scope: repo
+applies_to: [agents]
+related: [ultragoal, team, verify]
+created: "2026-07-29"
+last_reviewed: "2026-07-29"
+name: delivery-program
+description: "Run merge-last multi-blueprint programs through a typed delivery branch."
+argument-hint: "<parent-roadmap-slug>"
+---
+
+# Delivery Program
+
+Use this workflow when a typed `parent-roadmap` owns multiple child blueprints:
+
+```yaml
+delivery_branch: delivery/<program>
+delivery_base: main
+child_review_quorum: 1
+final_review_quorum: 1
+```
+
+Child membership comes only from `parent_roadmap`; do not maintain a second list.
+
+## Loop
+
+1. Call `wp_delivery_status({ slug })`.
+2. Treat its `version`, blockers, and exact returned action as the current derived
+   truth. Do not reconstruct state from transcripts.
+3. Dispatch only returned `wp_worktree` actions. Child work starts from the
+   delivery branch and child PRs target that branch.
+4. Integrate at most one child at a time. Recheck status immediately before
+   calling `wp_pr_merge` with the exact returned head SHA.
+5. An `enqueued` merge is not integrated. Call `wp_delivery_status` again and
+   wait for the merged postcondition.
+6. After every child PR is merged, verify the delivery branch and land its final
+   PR to `delivery_base` through the same exact-SHA merge tool.
+
+## Invariants
+
+- Executors do not merge their own PRs or act as their own outside reviewer.
+- Never push directly to the delivery branch or `main`.
+- Never use admin override, auto-merge, branch deletion, or a caller-invented SHA.
+- GitHub head matching is atomic; base matching is not. Preserve the reported
+  pre/post base evidence and rerun status after every mutation.
+- Use `queue_policy: merge_queue` only when policy explicitly requires it and
+  CI has a valid `merge_group` workflow. Queued state remains serialized.
+- Unknown dependencies, unverified completed children, stale heads, wrong bases,
+  path overlaps, missing review evidence, and partial provider state block landing.
+- Provider timeouts and discovery limits return blockers/warnings; do not increase
+  timeouts or bypass guards.
+
+Fallback when MCP is unavailable: `wp pr merge` uses the same exact-SHA service.

package/skills/design-review/SKILL.md

@@ -0,0 +1,26 @@
+---
+name: design-review
+description: "Report-first visual/browser design audit for hierarchy, spacing, consistency, responsive, a11y, and interactions."
+license: MIT
+allowed-tools:
+  - Read
+  - Glob
+  - Grep
+  - Bash
+---
+
+# Design review
+
+Use for live visual QA or design polish requests. For pre-implementation plan critique, use `/plan-design-review`.
+
+## Default behavior
+
+- 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.
+- Report first; do not edit source unless the user explicitly asks for fixes.
+- Inspect key viewports and states.
+- Capture evidence with browser screenshots or precise observations.
+- Rank findings by user impact and implementation effort.
+
+If fixes are authorized, make small visual changes and verify before/after.

package/skills/devex-review/SKILL.md

@@ -0,0 +1,28 @@
+---
+name: devex-review
+description: "Report-first developer-experience audit for onboarding, docs, examples, CLI help, and time-to-hello-world."
+license: MIT
+allowed-tools:
+  - Read
+  - Glob
+  - Grep
+  - Bash
+---
+
+# Live DX review
+
+Use after or during developer-facing work to test the real user journey.
+
+This is report-only by default. 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.
+
+## Evidence to gather
+
+- Docs route or README entrypoint.
+- Install/setup command path.
+- CLI help and error messages.
+- Time-to-hello-world estimate.
+- Browser evidence for docs or local app flows when relevant.
+
+Return a scorecard with blockers, papercuts, screenshots/artifacts when available, and concrete next fixes.