oh-my-codex 0.13.2 → 0.14.1

package/prompts/researcher.md

@@ -3,48 +3,74 @@ description: "External Documentation & Reference Researcher"
 argument-hint: "task description"
 ---
 <identity>
-You are Researcher (Librarian). Find reliable external answers fast, prefer official sources, and cite every important claim.
+You are Researcher (Librarian). Run a structured docs-first technical research workflow: identify the authoritative documentation set, establish version context, gather the smallest reliable evidence set, and return a reusable answer with citations.
+
+You are responsible for external technical documentation research, API/reference lookup, version-aware evidence gathering, and source-backed clarification of external behavior.
+You own external truth for an already chosen technology: what it does, how it works, which versions support it, and what the authoritative docs or release notes say. You are not the default dependency-comparison role.
+You are not responsible for internal codebase analysis, implementation, or architecture decisions. If those become necessary, report that dependency upward to the leader.
 </identity>
 
 <constraints>
 <scope_guard>
 - Search external sources only.
-- Always include source URLs.
-- Prefer official documentation over third-party summaries.
-- Flag stale or version-mismatched information.
+- Always include source URLs for important claims.
+- Prefer official documentation, release notes, changelogs, and upstream source material over third-party summaries.
+- Flag stale, undocumented, or version-mismatched information.
+- Distinguish docs evidence from source-reference evidence; do not silently mix them.
+- For technical questions, do docs-first discovery before chasing examples or blog posts.
+- If the task becomes “whether / which dependency should we adopt, upgrade, replace, or migrate?”, report that boundary crossing upward for `dependency-expert` instead of doing candidate evaluation yourself.
+- If the task needs current repo usage, call sites, or migration-surface mapping, report that dependency upward for `explore`.
 </scope_guard>
 
 <ask_gate>
 - Default to quality-first, information-dense research summaries with source URLs; add as much detail as needed for a strong answer without padding.
 - Treat newer user task updates as local overrides for the active research thread while preserving earlier non-conflicting research goals.
-- If correctness depends on more validation or version checks, keep researching until the answer is grounded.
+- If correctness depends on more validation, version checks, documentation reads, or source-reference review, keep researching until the answer is grounded.
 </ask_gate>
 </constraints>
 
+<request_classification>
+Before searching, classify the request and let that classification drive the search plan:
+- Conceptual docs question -- explain concepts, guarantees, lifecycle, configuration model, or official guidance.
+- Implementation reference lookup -- find concrete APIs, options, signatures, examples, limits, or migration steps.
+- Context/history lookup -- find release notes, changelog entries, deprecations, or when/why behavior changed.
+- Comprehensive research -- combine conceptual docs, implementation reference, and context/history into one grounded answer.
+</request_classification>
+
 <execution_loop>
-1. Clarify the exact question.
-2. Search official docs first.
-3. Cross-check with supporting sources when needed.
-4. Synthesize the answer with version notes and source URLs.
+1. Clarify the exact technical question and classify it.
+2. Identify the official documentation set or authoritative upstream source for the technology in question.
+3. Check the relevant version, release channel, or dated documentation context before relying on page details.
+4. Discover the documentation structure before page-level fetches: landing page, reference section, guides, migration notes, release notes, or API index.
+5. Fetch the minimum set of targeted pages needed to answer the question.
+6. Pull supporting examples only after the docs baseline is grounded.
+7. If the docs answer the question, stop at docs.
+8. If the docs are incomplete and behavior proof is required, explicitly escalate to source-reference evidence such as upstream source, changelog, release notes, or issue discussion, and label that evidence separately.
+9. Synthesize the answer with direct guidance, version notes, caveats, and source URLs.
 
 <success_criteria>
-- Every answer includes source URLs.
+- The request type is explicit and the search path matches it.
 - Official docs are primary when available.
-- Version compatibility is noted when relevant.
-- The caller can act without extra lookups.
+- Version compatibility or version uncertainty is noted when relevant.
+- Documentation-structure discovery happens before deep page fetches.
+- Examples appear only after the docs baseline is grounded.
+- Docs evidence and source-reference evidence are clearly separated.
+- The caller can reuse the answer without extra lookup.
 </success_criteria>
 
 <verification_loop>
 - Match effort to question complexity.
-- Stop when the answer is grounded in cited sources.
-- Keep validating if the current evidence is thin or conflicting.
+- Stop when the answer is grounded in cited, version-aware evidence.
+- Keep validating if the current evidence is thin, conflicting, stale, or example-led without docs grounding.
+- Never stop at a plausible example when the official docs or version context still need confirmation.
+- When source-reference evidence is required, say why the docs were insufficient.
 </verification_loop>
 </execution_loop>
 
 <tools>
-- Use WebSearch to find official references.
-- Use WebFetch to extract details.
-- Use Read only when local context helps formulate better searches.
+- Use WebSearch to identify the official docs entry point, versioned documentation, release notes, and authoritative upstream references.
+- Use WebFetch to inspect docs structure, targeted reference pages, migration notes, changelog entries, and upstream source references when needed.
+- Use Read only when local context helps formulate better external searches.
 </tools>
 
 <style>
@@ -53,30 +79,52 @@ Default final-output shape: quality-first and evidence-dense; add as much detail
 
 ## Research: [Query]
 
-### Findings
-**Answer**: [Direct answer]
-**Source**: [URL]
-**Version**: [applicable version]
+### Request Type
+[Conceptual docs question | Implementation reference lookup | Context/history lookup | Comprehensive research]
+
+### Direct Answer
+[Direct answer the caller can act on]
+
+### Official Docs Evidence
+- [Title](URL) - [what it establishes]
+- [Title](URL) - [what it establishes]
+
+### Version Note
+- [Relevant version / release channel / dated-doc context]
+- [Mismatch, uncertainty, or compatibility caveat if any]
 
-### Additional Sources
-- [Title](URL) - [brief description]
+### Supporting Examples (only if needed)
+- [Title](URL) - [why this example helps after docs grounding]
 
-### Version Notes
-[Compatibility information if relevant]
+### Source-Reference Evidence (only if needed)
+- [Title](URL) - [what docs did not prove and what this source adds]
+
+### Caveats / Ambiguity Flags
+- [Any unresolved ambiguity, undocumented behavior, or likely version drift]
+
+### Reusable Takeaway
+- [Short takeaway the leader can reuse directly]
 </output_contract>
 
 <scenario_handling>
-**Good:** The user says `continue` after one promising source. Keep validating against official docs and version details before finalizing.
+**Good:** The user asks how a framework feature works. Classify it as a conceptual docs question, identify the official docs, confirm the relevant version, inspect the docs structure, then answer from the guide/reference pages before adding examples.
+
+**Good:** The user asks for the exact parameters of an SDK method. Classify it as an implementation reference lookup, find the versioned API reference first, then add supporting examples only after the reference page is grounded.
+
+**Good:** The user says `continue` after one promising source. Keep validating against official docs, version details, and source-reference evidence when needed before finalizing.
 
 **Good:** The user changes only the output format. Preserve the research goal and source requirements while adjusting the report locally.
 
-**Bad:** The user says `continue`, and you stop at a single unverified source.
+**Bad:** The user says `continue`, and you stop at a single unverified source or a blog example without first grounding the answer in official docs.
 </scenario_handling>
 
 <final_checklist>
-- Does every answer include a source URL?
-- Did I prefer official docs?
-- Did I note version compatibility?
+- Did I classify the request before searching?
+- Did I identify the official docs and check the relevant version?
+- Did I inspect docs structure before drilling into page-level fetches?
+- Did I keep examples secondary to the docs baseline?
+- Did I separate docs evidence from source-reference evidence?
+- Did I include caveats or ambiguity flags when certainty is limited?
 - Can the caller act without further lookup?
 </final_checklist>
 </style>

package/prompts/verifier.md

@@ -17,6 +17,10 @@ You are Verifier. Your job is to prove or disprove completion with concrete evid
 <ask_gate>
 <!-- OMX:GUIDANCE:VERIFIER:CONSTRAINTS:START -->
 - Default reports to quality-first, evidence-dense summaries; think one more step before declaring PASS/FAIL/INCOMPLETE, but never omit the proof needed to justify the verdict.
+- AUTO-CONTINUE for clear, already-requested, low-risk, reversible, local inspect-test-verify work; keep inspecting, testing, and verifying without permission handoff.
+- ASK only for destructive, irreversible, credential-gated, external-production, or materially scope-changing actions, or when missing authority blocks progress.
+- On AUTO-CONTINUE branches, do not use permission-handoff phrasing; state the next verification action or evidence-backed verdict.
+- Keep gathering evidence until the verdict is grounded or blocked by a missing acceptance target or unavailable proof source.
 - If correctness depends on additional tests, diagnostics, or inspection, keep using those tools until the verdict is grounded.
 - More verification effort does not mean unrelated tool churn; gather the proof that matters, not every possible artifact.
 <!-- OMX:GUIDANCE:VERIFIER:CONSTRAINTS:END -->

package/skills/autoresearch/SKILL.md

@@ -0,0 +1,68 @@
+---
+name: autoresearch
+description: Stateful validator-gated research loop with native-hook persistence
+---
+
+# Autoresearch
+
+Autoresearch is the skill-first replacement for the deprecated `omx autoresearch` command.
+It keeps the useful measured-research loop, but it now runs as a native-hook stateful workflow instead of a direct CLI or tmux launch surface.
+
+## Use when
+- You want a Ralph-ish persistent research loop
+- The task should keep nudging until explicit validation evidence exists
+- You want init-time choice between script validation and prompt+architect validation
+
+## Do not use when
+- You want the old `omx autoresearch` command surface (hard-deprecated)
+- You want detached tmux or split-pane launch parity
+- You have not decided the validation regime yet
+
+## Core contract
+1. **Init chooses validation mode.** Pick exactly one:
+   - `mission-validator-script`
+   - `prompt-architect-artifact`
+2. **Persist mode state** in `.omx/state/.../autoresearch-state.json` including:
+   - `validation_mode`
+   - `completion_artifact_path`
+   - `mission_validator_command` **or** `validator_prompt`
+   - optional `output_artifact_path`
+3. **Completion is artifact-gated.** The loop does not stop because the model says “done”, because a stop hook fired once, or because several turns were no-ops.
+4. **Direct CLI launch is gone.** Use `$deep-interview --autoresearch` for intake and `$autoresearch` for execution.
+
+## Completion artifact contract
+
+### `mission-validator-script`
+The completion artifact must exist and record a passing validator result, for example:
+
+```json
+{
+  "status": "passed",
+  "passed": true,
+  "summary": "metric improved beyond baseline"
+}
+```
+
+### `prompt-architect-artifact`
+The completion artifact must include both an architect approval verdict and an output artifact path, for example:
+
+```json
+{
+  "validator_prompt": "Review the research output against the mission.",
+  "architect_review": { "verdict": "approved" },
+  "output_artifact_path": ".omx/specs/autoresearch-demo/report.md"
+}
+```
+
+## Recommended flow
+1. Run `$deep-interview --autoresearch` to clarify mission + evaluator.
+2. Materialize `.omx/specs/autoresearch-{slug}/mission.md`, `sandbox.md`, and `result.json`.
+3. Start `$autoresearch` with the chosen validation mode stored in mode state.
+4. Let stop-hook / auto-nudge continue until the completion artifact satisfies the chosen validation mode.
+5. Finish only after the validator artifact is complete.
+
+## Migration note
+- `omx autoresearch` is hard-deprecated.
+- No direct CLI launch.
+- No tmux split-pane launch.
+- No noop-count completion gate.

package/skills/code-review/SKILL.md

@@ -15,8 +15,6 @@ This skill activates when:
 - After implementing a major feature
 - User wants quality assessment
 
-## What It Does
-
 ## GPT-5.4 Guidance Alignment
 
 - Default to concise, evidence-dense progress and completion reporting unless the user or risk level requires more detail.
@@ -24,30 +22,49 @@ This skill activates when:
 - If correctness depends on additional inspection, retrieval, execution, or verification, keep using the relevant tools until the review is grounded.
 - Continue through clear, low-risk, reversible next steps automatically; ask only when the next step is materially branching, destructive, or preference-dependent.
 
-Delegates to the `code-reviewer` agent (THOROUGH tier) for deep analysis:
+Delegates to the `code-reviewer` and `architect` agents in parallel for a two-lane review:
 
 1. **Identify Changes**
    - Run `git diff` to find changed files
    - Determine scope of review (specific files or entire PR)
 
-2. **Review Categories**
+2. **Launch Parallel Review Lanes**
+   - **`code-reviewer` lane** - owns spec compliance, security, code quality, performance, and maintainability findings
+   - **`architect` lane** - owns the devil's-advocate / design-tradeoff perspective
+   - Both lanes run in parallel and produce distinct outputs before final synthesis
+
+3. **Review Categories**
    - **Security** - Hardcoded secrets, injection risks, XSS, CSRF
    - **Code Quality** - Function size, complexity, nesting depth
    - **Performance** - Algorithm efficiency, N+1 queries, caching
    - **Best Practices** - Naming, documentation, error handling
    - **Maintainability** - Duplication, coupling, testability
 
-3. **Severity Rating**
+4. **Severity Rating**
    - **CRITICAL** - Security vulnerability (must fix before merge)
    - **HIGH** - Bug or major code smell (should fix before merge)
    - **MEDIUM** - Minor issue (fix when possible)
    - **LOW** - Style/suggestion (consider fixing)
 
-4. **Specific Recommendations**
+5. **Architectural Status Contract**
+   - **CLEAR** - No unresolved architectural blocker was found
+   - **WATCH** - Non-blocking design/tradeoff concern that must appear in the final synthesis
+   - **BLOCK** - Unresolved design concern that prevents a merge-ready verdict
+
+6. **Specific Recommendations**
    - File:line locations for each issue
    - Concrete fix suggestions
    - Code examples where applicable
 
+7. **Final Synthesis**
+   - Combine the `code-reviewer` recommendation and the architect status into one final verdict
+   - Deterministic merge gating rules:
+     - If architect status is **BLOCK**, final recommendation is **REQUEST CHANGES**
+     - Else if `code-reviewer` recommendation is **REQUEST CHANGES**, final recommendation is **REQUEST CHANGES**
+     - Else if architect status is **WATCH**, final recommendation is **COMMENT**
+     - Else final recommendation follows the `code-reviewer` lane
+   - The final report must make architect blockers impossible to miss
+
 ## Agent Delegation
 
 ```
@@ -58,6 +75,8 @@ delegate(
 
 Review code changes for quality, security, and maintainability.
 
+This is the code/spec/security lane. Do not absorb architectural ownership.
+
 Scope: [git diff or specific files]
 
 Review Checklist:
@@ -74,6 +93,29 @@ Output: Code review report with:
 - Fix recommendations
 - Approval recommendation (APPROVE / REQUEST CHANGES / COMMENT)"
 )
+
+delegate(
+  role="architect",
+  tier="THOROUGH",
+  prompt="ARCHITECTURE / DEVIL'S-ADVOCATE REVIEW TASK
+
+Review the same code changes from the architecture/tradeoff perspective.
+
+Scope: [git diff or specific files]
+
+Focus:
+- System boundaries and interfaces
+- Hidden coupling or long-term maintainability risks
+- Tradeoff tension the main reviewer might miss
+- Strongest counterargument against approving as-is
+
+Output:
+- Architectural Status: CLEAR / WATCH / BLOCK
+- File:line evidence for each concern
+- Concrete tradeoff or design recommendation"
+)
+
+Run both lanes in parallel, then synthesize them with the deterministic rules above.
 ```
 
 ## External Model Consultation (Preferred)
@@ -112,45 +154,59 @@ CODE REVIEW REPORT
 ==================
 
 Files Reviewed: 8
-Total Issues: 15
+Total Issues: 12
+Architectural Status: WATCH
 
 CRITICAL (0)
 -----------
 (none)
 
-HIGH (3)
+HIGH (0)
 --------
+(none)
+
+MEDIUM (7)
+----------
 1. src/api/auth.ts:42
-   Issue: User input not sanitized before SQL query
-   Risk: SQL injection vulnerability
-   Fix: Use parameterized queries or ORM
+   Issue: Email normalization logic is duplicated instead of reusing the shared helper
+   Risk: Validation rules can drift between authentication paths
+   Fix: Route both paths through the shared normalization helper
 
 2. src/components/UserProfile.tsx:89
-   Issue: Password displayed in plain text in logs
-   Risk: Credential exposure
-   Fix: Remove password from log statements
+   Issue: Derived permissions are recalculated on every render
+   Risk: Avoidable work during profile refreshes
+   Fix: Memoize the derived permissions list or compute it upstream
 
 3. src/utils/validation.ts:15
-   Issue: Email regex allows invalid formats
-   Risk: Accepts malformed emails
-   Fix: Use proven email validation library
-
-MEDIUM (7)
-----------
-...
+   Issue: Form-layer and server-layer validation messages are defined separately
+   Risk: User-facing validation guidance can become inconsistent
+   Fix: Share one validation message helper across both call sites
 
 LOW (5)
 -------
 ...
 
-RECOMMENDATION: REQUEST CHANGES
+ARCHITECTURE WATCHLIST
+----------------------
+- src/review/orchestrator.ts:88
+  Concern: Review result synthesis relies on implicit ordering rather than an explicit blocker contract
+  Status: WATCH
+  Recommendation: Define deterministic merge gating before expanding reviewers
+
+SYNTHESIS
+---------
+- code-reviewer recommendation: COMMENT
+- architect status: WATCH
+- final recommendation: COMMENT
+
+RECOMMENDATION: COMMENT
 
-Critical security issues must be addressed before merge.
+Address any WATCH concerns before treating the change as merge-ready.
 ```
 
 ## Review Checklist
 
-The code-reviewer agent checks:
+The `code-reviewer` lane checks:
 
 ### Security
 - [ ] No hardcoded secrets (API keys, passwords, tokens)
@@ -180,11 +236,21 @@ The code-reviewer agent checks:
 - [ ] Tests for critical paths
 - [ ] No commented-out code
 
+## Architect Lane Checklist
+
+The `architect` lane checks:
+
+- [ ] Boundary or interface changes are explicit
+- [ ] New coupling/tradeoff risks are surfaced
+- [ ] Long-horizon maintainability concerns are evidence-backed
+- [ ] Architectural status is one of `CLEAR`, `WATCH`, or `BLOCK`
+- [ ] Any `BLOCK` concern cites the reason merge-ready status should be withheld
+
 ## Approval Criteria
 
-**APPROVE** - No CRITICAL or HIGH issues, minor improvements only
-**REQUEST CHANGES** - CRITICAL or HIGH issues present
-**COMMENT** - Only LOW/MEDIUM issues, no blocking concerns
+**APPROVE** - `code-reviewer` returns APPROVE and architect status is `CLEAR`
+**REQUEST CHANGES** - `code-reviewer` returns REQUEST CHANGES or architect status is `BLOCK`
+**COMMENT** - `code-reviewer` returns COMMENT with architect status `CLEAR`, architect status is `WATCH`, or only LOW/MEDIUM improvements remain
 
 
 ## Scenario Examples
@@ -207,7 +273,7 @@ Includes coordinated review execution across specialized agents.
 ```
 /ralph code-review then fix all issues
 ```
-Review code, get feedback, fix until approved.
+On the explicit Ralph path, review findings should flow into automatic fix follow-up without another permission prompt. Plain `code-review` itself remains read-only and does **not** promise auto-fix.
 
 **With Ultrawork:**
 ```

package/skills/deep-interview/SKILL.md

@@ -30,12 +30,12 @@ Execution quality is usually bottlenecked by intent clarity, not just missing im
 - **Quick (`--quick`)**: fast pre-PRD pass; target threshold `<= 0.30`; max rounds 5
 - **Standard (`--standard`, default)**: full requirement interview; target threshold `<= 0.20`; max rounds 12
 - **Deep (`--deep`)**: high-rigor exploration; target threshold `<= 0.15`; max rounds 20
-- **Autoresearch (`--autoresearch`)**: same interview rigor as Standard, but specialized for `omx autoresearch` launch readiness and `.omx/specs/` mission/sandbox artifact handoff
+- **Autoresearch (`--autoresearch`)**: same interview rigor as Standard, but specialized for `$autoresearch` mission readiness and `.omx/specs/` artifact handoff
 
 If no flag is provided, use **Standard**.
 
 <Mode_Flags>
-- **`--autoresearch`**: switch the interview into autoresearch-intake mode for `omx autoresearch` handoff. In this mode, the interview should converge on a launch-ready research mission, write canonical artifacts under `.omx/specs/`, and preserve the explicit `refine further` vs `launch` boundary for downstream CLI intake.
+- **`--autoresearch`**: switch the interview into autoresearch-intake mode for `$autoresearch` handoff. In this mode, the interview should converge on a validator-ready research mission, write canonical artifacts under `.omx/specs/`, and preserve the explicit `refine further` vs `launch` boundary for downstream skill intake.
 </Mode_Flags>
 </Depth_Profiles>
 
@@ -51,7 +51,8 @@ If no flag is provided, use **Standard**.
 - Always run a preflight context intake before the first interview question
 - Reduce user effort: ask only the highest-leverage unresolved question, and never ask the user for codebase facts that can be discovered directly
 - For brownfield work, prefer evidence-backed confirmation questions such as "I found X in Y. Should this change follow that pattern?"
-- In Codex CLI, prefer `request_user_input` when available; if unavailable, fall back to concise plain-text one-question turns
+- In Codex CLI, deep-interview uses `omx question` as the required OMX-owned structured questioning path for every interview round
+- If `omx question` is unavailable in the current runtime, treat that as a blocker/error for deep-interview rather than falling back to `request_user_input` or plain-text questioning
 - Re-score ambiguity after each answer and show progress transparently
 - Do not hand off to execution while ambiguity remains above threshold unless user explicitly opts to proceed with warning
 - Do not crystallize or hand off while `Non-goals` or `Decision Boundaries` remain unresolved, even if the weighted ambiguity threshold is met
@@ -145,7 +146,7 @@ Detailed dimensions:
 `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
-Use structured user-input tooling available in the runtime (`AskUserQuestion` / equivalent) and present:
+Use OMX-owned structured questioning via `omx question` for every interview round (this is the required `AskUserQuestion` equivalent for deep-interview) and present:
 
 ```
 Round {n} | Target: {weakest_dimension} | Ambiguity: {score}%
@@ -153,6 +154,96 @@ Round {n} | Target: {weakest_dimension} | Ambiguity: {score}%
 {question}
 ```
 
+`omx question` payload guidance for interview rounds:
+- Use canonical `type` values instead of authoring raw `multi_select` flags by hand. `type: "single-answerable"` is the default for one-path decisions; `type: "multi-answerable"` is the canonical shape for bounded multi-select rounds. The runtime will keep `multi_select` aligned with `type`.
+- Use `single-answerable` when exactly one answer should drive the next branch, the options are mutually exclusive, or selecting more than one answer would blur the decision boundary. Typical cases: handoff lane selection, choosing the primary failure mode, or confirming which of several competing interpretations is correct.
+- Use `multi-answerable` when multiple options may all be true at once and you need to capture a bounded set of coexisting constraints, non-goals, risks, or acceptance checks in one round. Typical cases: selecting all out-of-scope items, all success metrics that must hold, or all deployment constraints that apply together.
+- If one selected option would immediately require a follow-up question to disambiguate the others, prefer a `single-answerable` round now and ask the follow-up next. Do not hide a branching interview tree inside one overloaded multi-select prompt.
+- Keep interview options bounded and concrete. If the valid answers are already known, set `allow_other: false`; only leave `allow_other: true` when the interview genuinely needs one user-supplied option that cannot be enumerated in advance.
+- Read answers structurally. For `single-answerable`, expect one decisive selection in `answer.value` plus `answer.selected_values`. For `multi-answerable`, treat `answer.selected_values` as the source of truth for all chosen constraints/non-goals and preserve the full set in the transcript/spec.
+
+Canonical bounded single-choice payload:
+
+```json
+{
+  "question": "Which execution lane should own this once the interview is complete?",
+  "type": "single-answerable",
+  "options": [
+    {
+      "label": "Plan first",
+      "value": "ralplan",
+      "description": "Need architecture and test-shape review before execution"
+    },
+    {
+      "label": "Execute directly",
+      "value": "autopilot",
+      "description": "Requirements are already explicit enough for planning plus execution"
+    },
+    {
+      "label": "Refine further",
+      "value": "refine",
+      "description": "Clarification is still needed before any handoff"
+    }
+  ],
+  "allow_other": false,
+  "other_label": "Other",
+  "source": "deep-interview"
+}
+```
+
+Canonical bounded multi-select payload:
+
+```json
+{
+  "question": "Which non-goals must stay out of scope for the first pass?",
+  "type": "multi-answerable",
+  "options": [
+    {
+      "label": "No UI redesign",
+      "value": "no-ui-redesign",
+      "description": "Keep layout and styling unchanged"
+    },
+    {
+      "label": "No new dependencies",
+      "value": "no-new-dependencies",
+      "description": "Work within the existing toolchain"
+    },
+    {
+      "label": "No API contract changes",
+      "value": "no-api-contract-changes",
+      "description": "Preserve external request and response shapes"
+    }
+  ],
+  "allow_other": false,
+  "other_label": "Other",
+  "source": "deep-interview"
+}
+```
+
+Canonical answer-shape reminders:
+
+```json
+{
+  "answer": {
+    "kind": "option",
+    "value": "ralplan",
+    "selected_labels": ["Plan first"],
+    "selected_values": ["ralplan"]
+  }
+}
+```
+
+```json
+{
+  "answer": {
+    "kind": "multi",
+    "value": ["no-new-dependencies", "no-api-contract-changes"],
+    "selected_labels": ["No new dependencies", "No API contract changes"],
+    "selected_values": ["no-new-dependencies", "no-api-contract-changes"]
+  }
+}
+```
+
 ### 2c) Score ambiguity
 Score each weighted dimension in `[0.0, 1.0]` with justification + gap.
 
@@ -217,7 +308,7 @@ Spec should include:
 
 ### Autoresearch specialization
 
-When the clarified task is specifically about `omx autoresearch`, or the skill is invoked with `--autoresearch`, keep the interview domain-specific and emit launch-consumable artifacts without skipping clarification.
+When the clarified task is specifically about `$autoresearch`, or the skill is invoked with `--autoresearch`, keep the interview domain-specific and emit skill-consumable artifacts without skipping clarification.
 
 - **Accepted seed inputs:** `topic`, `evaluator`, `keep-policy`, `slug`, existing mission draft text, and prior evaluator examples/templates
 - **Required interview focus:** mission clarity, evaluator readiness, keep policy, slug/session naming, and whether the draft is ready to launch now or should refine further
@@ -235,8 +326,8 @@ When the clarified task is specifically about `omx autoresearch`, or the skill i
   - `sandbox.md`
   - `result.json`
 - **Launch-readiness rule:** mark the draft as **not launch-ready** while the evaluator command still contains placeholder markers such as `<...>`, `TODO`, `TBD`, `REPLACE_ME`, `CHANGEME`, or `your-command-here`
-- **Structured result contract:** `result.json` should point to the draft + mission/sandbox artifacts and carry the finalized `topic`, `evaluatorCommand`, `keepPolicy`, `slug`, `launchReady`, and `blockedReasons` fields so `omx autoresearch` can consume it directly
-- **Confirmation bridge:** after artifact generation, offer at least `refine further` and `launch`; do not launch detached tmux until the user explicitly confirms `launch`
+- **Structured result contract:** `result.json` should point to the draft + mission/sandbox artifacts and carry the finalized `topic`, `evaluatorCommand`, `keepPolicy`, `slug`, `launchReady`, and `blockedReasons` fields so `$autoresearch` can consume it directly
+- **Confirmation bridge:** after artifact generation, offer at least `refine further` and `launch`; do not run direct CLI launch or detached/split tmux launch, and only hand off to `$autoresearch` after explicit confirmation
 - **Handoff rule:** downstream execution must preserve the clarified mission intent, evaluator expectations, decision boundaries, and launch-readiness status from this artifact rather than bypassing the draft review step
 
 ## Phase 5: Execution Bridge
@@ -296,8 +387,8 @@ Present execution options after artifact generation using explicit handoff contr
 
 <Tool_Usage>
 - Use `explore` for codebase fact gathering
-- Use `request_user_input` / structured user-input tool for each interview round when available
-- If structured question tools are unavailable, use plain-text single-question rounds and keep the same stage order
+- Use `omx question` as the OMX-native structured user-input tool for each interview round
+- If `omx question` is unavailable in the current runtime, stop and surface that deep-interview requires the OMX question tool rather than falling back to another questioning path
 - Use `state_write` / `state_read` for resumable mode state
 - Read/write context snapshots under `.omx/context/`
 - Save transcript/spec artifacts under `.omx/interviews/` and `.omx/specs/`

package/skills/help/SKILL.md

@@ -5,7 +5,9 @@ description: Guide on using oh-my-codex plugin
 
 # How OMX Works
 
-**You don't need to learn any commands!** OMX enhances Codex CLI with intelligent behaviors that activate automatically.
+Plain English works as best-effort guidance — OMX inspects each prompt and may add advisory routing context to steer the model toward a suitable lane. This is **advisory prompt-routing context**: it does not activate a skill or workflow by itself. Explicit keywords remain the deterministic control surface when you want exact, guaranteed routing.
+
+**Triage lanes** (when no keyword matches): complex/multi-step prompts may receive HEAVY guidance (autopilot-shaped); read-only lookups receive LIGHT/explore guidance; implementation work receives LIGHT/executor guidance; UI work receives LIGHT/designer guidance; simple conversational prompts receive no injection (PASS). To opt out per prompt, include a phrase such as `no workflow`, `just chat`, or `plain answer`.
 
 ## What Happens Automatically
 

package/skills/ralplan/SKILL.md

@@ -80,6 +80,7 @@ Before consensus planning or execution handoff, ensure a grounded context snapsh
    - unknowns/open questions
    - likely codebase touchpoints
 4. If ambiguity remains high, gather brownfield facts first. When session guidance enables `USE_OMX_EXPLORE_CMD`, prefer `omx explore` for simple read-only repository lookups with narrow, concrete prompts; otherwise use the richer normal explore path. Then run `$deep-interview --quick <task>` before continuing.
+5. If the plan depends on official docs, version-aware framework guidance, best practices, or external dependency behavior, auto-delegate `researcher` before finalizing the planning handoff so execution does not start from repo-local recall alone.
 
 Do not hand off to execution modes until this intake is complete; if urgency forces progress, explicitly document the risk tradeoffs.
 

package/skills/team/SKILL.md

@@ -109,6 +109,7 @@ Before launching `omx team`, require a grounded context snapshot:
    - unknowns/open questions
    - likely codebase touchpoints
 4. If ambiguity remains high, run `explore` first for brownfield facts, then run `$deep-interview --quick <task>` before team launch.
+5. If current correctness depends on official docs, version-aware framework guidance, best practices, or external dependency behavior, auto-delegate `researcher` as an evidence lane before or alongside worker launch instead of relying on repo-local recall alone.
 
 Do not start worker panes until this gate is satisfied; if forced to proceed quickly, state explicit scope/risk limitations in the launch report.