[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6XDS93T7V2HDR7NPWCY15N9":3,"skill-same:01M6XDS93T7V2HDR7NPWCY15N9":64},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":44,"commitSha":45,"skillDirectory":46,"forksCount":14,"repositoryHtmlUrl":47,"repositoryHomepageUrl":6,"ownerHtmlUrl":48,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":49,"install":50,"resources":63},"01M6XDS93T7V2HDR7NPWCY15N9","deep-interview",null,"Socratic deep interview with mathematical ambiguity gating before execution","sapsapshen\u002Fai-memory-router","sapsapshen","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F20347959?v=4","01M6XDQEF1DP50DKF37H81J3J5","shenmian","01M6XDQEJPE41Y3DT2763X8ZJN",0,"MIT","https:\u002F\u002Fgithub.com\u002Fsapsapshen\u002Fai-memory-router\u002Fblob\u002Fmain\u002Fskills-store\u002Fcodex\u002Fdeep-interview\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000038","人力资源","PROFESSION","适用职业",[24,25,26,27,28,29,30,31,32,33,34,35,36,37],"interview","deep","deep interview","autoresearch","execution","idea","Mathematical","with","quick","ambiguity","vague","socratic","gating","standard","2026-11-10 10:12:30",false,"---\nname: deep-interview\ndescription: Socratic deep interview with mathematical ambiguity gating before execution\nargument-hint: \"[--quick|--standard|--deep] [--autoresearch] \u003Cidea or vague description>\"\n---\n\n\u003CPurpose>\nDeep Interview is an intent-first Socratic clarification loop before planning or implementation. It turns vague ideas into execution-ready specifications by asking targeted questions about why the user wants a change, how far it should go, what should stay out of scope, and what OMX may decide without confirmation.\n\u003C\u002FPurpose>\n\n\u003CUse_When>\n- The request is broad, ambiguous, or missing concrete acceptance criteria\n- The user says \"deep interview\", \"interview me\", \"ask me everything\", \"don't assume\", or \"ouroboros\"\n- The user wants to avoid misaligned implementation from underspecified requirements\n- You need a requirements artifact before handing off to `ralplan`, `autopilot`, `ralph`, or `team`\n\u003C\u002FUse_When>\n\n\u003CDo_Not_Use_When>\n- The request already has concrete file\u002Fsymbol targets and clear acceptance criteria\n- The user explicitly asks to skip planning\u002Finterview and execute immediately\n- The user asks for lightweight brainstorming only (use `plan` instead)\n- A complete PRD\u002Fplan already exists and execution should start\n\u003C\u002FDo_Not_Use_When>\n\n\u003CWhy_This_Exists>\nExecution 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 the scope should stop, which tradeoffs are unacceptable, and which decisions still require user approval. This workflow applies Socratic pressure + quantitative ambiguity scoring so orchestration modes begin with an explicit, testable, intent-aligned spec.\n\u003C\u002FWhy_This_Exists>\n\n\u003CDepth_Profiles>\n- **Quick (`--quick`)**: fast pre-PRD pass; target threshold `\u003C= 0.30`; max rounds 5\n- **Standard (`--standard`, default)**: full requirement interview; target threshold `\u003C= 0.20`; max rounds 12\n- **Deep (`--deep`)**: high-rigor exploration; target threshold `\u003C= 0.15`; max rounds 20\n- **Autoresearch (`--autoresearch`)**: same interview rigor as Standard, but specialized for `omx autoresearch` launch readiness and `.omx\u002Fspecs\u002F` mission\u002Fsandbox artifact handoff\n\nIf no flag is provided, use **Standard**.\n\n\u003CMode_Flags>\n- **`--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\u002Fspecs\u002F`, and preserve the explicit `refine further` vs `launch` boundary for downstream CLI intake.\n\u003C\u002FMode_Flags>\n\u003C\u002FDepth_Profiles>\n\n\u003CExecution_Policy>\n- Ask ONE question per round (never batch)\n- Ask about intent and boundaries before implementation detail\n- Target the weakest clarity dimension each round after applying the stage-priority rules below\n- Treat every answer as a claim to pressure-test before moving on: the next question should usually demand evidence or examples, expose a hidden assumption, force a tradeoff or boundary, or reframe root cause vs symptom\n- Do not rotate to a new clarity dimension just for coverage when the current answer is still vague; stay on the same thread until one layer deeper, one assumption clearer, or one boundary tighter\n- Before crystallizing, complete at least one explicit pressure pass that revisits an earlier answer with a deeper, assumption-focused, or tradeoff-focused follow-up\n- Gather codebase facts via `explore` before asking user about internals\n- When session guidance enables `USE_OMX_EXPLORE_CMD`, prefer `omx explore` for simple read-only brownfield fact gathering; keep prompts narrow and concrete, and keep ambiguous or non-shell-only investigation on the richer normal path and fall back normally if `omx explore` is unavailable.\n- Always run a preflight context intake before the first interview question\n- Reduce user effort: ask only the highest-leverage unresolved question, and never ask the user for codebase facts that can be discovered directly\n- For brownfield work, prefer evidence-backed confirmation questions such as \"I found X in Y. Should this change follow that pattern?\"\n- In Codex CLI, prefer `request_user_input` when available; if unavailable, fall back to concise plain-text one-question turns\n- Re-score ambiguity after each answer and show progress transparently\n- Do not hand off to execution while ambiguity remains above threshold unless user explicitly opts to proceed with warning\n- Do not crystallize or hand off while `Non-goals` or `Decision Boundaries` remain unresolved, even if the weighted ambiguity threshold is met\n- Treat early exit as a safety valve, not the default success path\n- Persist mode state for resume safety (`state_write` \u002F `state_read`)\n\u003C\u002FExecution_Policy>\n\n\u003CSteps>\n\n## Phase 0: Preflight Context Intake\n\n1. Parse `{{ARGUMENTS}}` and derive a short task slug.\n2. Attempt to load the latest relevant context snapshot from `.omx\u002Fcontext\u002F{slug}-*.md`.\n3. If no snapshot exists, create a minimum context snapshot with:\n   - Task statement\n   - Desired outcome\n   - Stated solution (what the user asked for)\n   - Probable intent hypothesis (why they likely want it)\n   - Known facts\u002Fevidence\n   - Constraints\n   - Unknowns\u002Fopen questions\n   - Decision-boundary unknowns\n   - Likely codebase touchpoints\n4. Save snapshot to `.omx\u002Fcontext\u002F{slug}-{timestamp}.md` (UTC `YYYYMMDDTHHMMSSZ`) and reference it in mode state.\n\n## Phase 1: Initialize\n\n1. Parse `{{ARGUMENTS}}` and depth profile (`--quick|--standard|--deep`).\n2. Detect project context:\n   - Run `explore` to classify **brownfield** (existing codebase target) vs **greenfield**.\n   - For brownfield, collect relevant codebase context before questioning.\n3. Initialize state via `state_write(mode=\"deep-interview\")`:\n\n```json\n{\n  \"active\": true,\n  \"current_phase\": \"deep-interview\",\n  \"state\": {\n    \"interview_id\": \"\u003Cuuid>\",\n    \"profile\": \"quick|standard|deep\",\n    \"type\": \"greenfield|brownfield\",\n    \"initial_idea\": \"\u003Cuser input>\",\n    \"rounds\": [],\n    \"current_ambiguity\": 1.0,\n    \"threshold\": 0.3,\n    \"max_rounds\": 5,\n    \"challenge_modes_used\": [],\n    \"codebase_context\": null,\n    \"current_stage\": \"intent-first\",\n    \"current_focus\": \"intent\",\n    \"context_snapshot_path\": \".omx\u002Fcontext\u002F\u003Cslug>-\u003Ctimestamp>.md\"\n  }\n}\n```\n\n4. Announce kickoff with profile, threshold, and current ambiguity.\n\n## Phase 2: Socratic Interview Loop\n\nRepeat until ambiguity `\u003C= threshold`, the pressure pass is complete, the readiness gates are explicit, the user exits with warning, or max rounds are reached.\n\n### 2a) Generate next question\nUse:\n- Original idea\n- Prior Q&A rounds\n- Current dimension scores\n- Brownfield context (if any)\n- Activated challenge mode injection (Phase 3)\n\nTarget the lowest-scoring dimension, but respect stage priority:\n- **Stage 1 — Intent-first:** Intent, Outcome, Scope, Non-goals, Decision Boundaries\n- **Stage 2 — Feasibility:** Constraints, Success Criteria\n- **Stage 3 — Brownfield grounding:** Context Clarity (brownfield only)\n\nFollow-up pressure ladder after each answer:\n1. Ask for a concrete example, counterexample, or evidence signal behind the latest claim\n2. Probe the hidden assumption, dependency, or belief that makes the claim true\n3. Force a boundary or tradeoff: what would you explicitly not do, defer, or reject?\n4. If the answer still describes symptoms, reframe toward essence \u002F root cause before moving on\n\nPrefer staying on the same thread for multiple rounds when it has the highest leverage. Breadth without pressure is not progress.\n\nDetailed dimensions:\n- Intent Clarity — why the user wants this\n- Outcome Clarity — what end state they want\n- Scope Clarity — how far the change should go\n- Constraint Clarity — technical or business limits that must hold\n- Success Criteria Clarity — how completion will be judged\n- Context Clarity — existing codebase understanding (brownfield only)\n\n`Non-goals` and `Decision Boundaries` are mandatory readiness gates. Ask about them early and keep revisiting them until they are explicit.\n\n### 2b) Ask the question\nUse structured user-input tooling available in the runtime (`AskUserQuestion` \u002F equivalent) and present:\n\n```\nRound {n} | Target: {weakest_dimension} | Ambiguity: {score}%\n\n{question}\n```\n\n### 2c) Score ambiguity\nScore each weighted dimension in `[0.0, 1.0]` with justification + gap.\n\nGreenfield: `ambiguity = 1 - (intent × 0.30 + outcome × 0.25 + scope × 0.20 + constraints × 0.15 + success × 0.10)`\n\nBrownfield: `ambiguity = 1 - (intent × 0.25 + outcome × 0.20 + scope × 0.20 + constraints × 0.15 + success × 0.10 + context × 0.10)`\n\nReadiness gate:\n- `Non-goals` must be explicit\n- `Decision Boundaries` must be explicit\n- A pressure pass must be complete: at least one earlier answer has been revisited with an evidence, assumption, or tradeoff follow-up\n- If either gate is unresolved, or the pressure pass is incomplete, continue interviewing even when weighted ambiguity is below threshold\n\n### 2d) Report progress\nShow weighted breakdown table, readiness-gate status (`Non-goals`, `Decision Boundaries`), and the next focus dimension.\n\n### 2e) Persist state\nAppend round result and updated scores via `state_write`.\n\n### 2f) Round controls\n- Do not offer early exit before the first explicit assumption probe and one persistent follow-up have happened\n- Round 4+: allow explicit early exit with risk warning\n- Soft warning at profile midpoint (e.g., round 3\u002F6\u002F10 depending on profile)\n- Hard cap at profile `max_rounds`\n\n## Phase 3: Challenge Modes (assumption stress tests)\n\nUse each mode once when applicable. These are normal escalation tools, not rare rescue moves:\n\n- **Contrarian** (round 2+ or immediately when an answer rests on an untested assumption): challenge core assumptions\n- **Simplifier** (round 4+ or when scope expands faster than outcome clarity): probe minimal viable scope\n- **Ontologist** (round 5+ and ambiguity > 0.25, or when the user keeps describing symptoms): ask for essence-level reframing\n\nTrack used modes in state to prevent repetition.\n\n## Phase 4: Crystallize Artifacts\n\nWhen threshold is met (or user exits with warning \u002F hard cap):\n\n1. Write interview transcript summary to:\n   - `.omx\u002Finterviews\u002F{slug}-{timestamp}.md`  \n     (kept for ralph PRD compatibility)\n2. Write execution-ready spec to:\n   - `.omx\u002Fspecs\u002Fdeep-interview-{slug}.md`\n\nSpec should include:\n- Metadata (profile, rounds, final ambiguity, threshold, context type)\n- Context snapshot reference\u002Fpath (for ralplan\u002Fteam reuse)\n- Clarity breakdown table\n- Intent (why the user wants this)\n- Desired Outcome\n- In-Scope\n- Out-of-Scope \u002F Non-goals\n- Decision Boundaries (what OMX may decide without confirmation)\n- Constraints\n- Testable acceptance criteria\n- Assumptions exposed + resolutions\n- Pressure-pass findings (which answer was revisited, and what changed)\n- Brownfield evidence vs inference notes for any repository-grounded confirmation questions\n- Technical context findings\n- Full or condensed transcript\n\n### Autoresearch specialization\n\nWhen 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.\n\n- **Accepted seed inputs:** `topic`, `evaluator`, `keep-policy`, `slug`, existing mission draft text, and prior evaluator examples\u002Ftemplates\n- **Required interview focus:** mission clarity, evaluator readiness, keep policy, slug\u002Fsession naming, and whether the draft is ready to launch now or should refine further\n- **Canonical artifact path:** `.omx\u002Fspecs\u002Fdeep-interview-autoresearch-{slug}.md`\n- **Launch artifact bundle:** `.omx\u002Fspecs\u002Fautoresearch-{slug}\u002Fmission.md`, `.omx\u002Fspecs\u002Fautoresearch-{slug}\u002Fsandbox.md`, and `.omx\u002Fspecs\u002Fautoresearch-{slug}\u002Fresult.json`\n- **Launch artifact directory:** `.omx\u002Fspecs\u002Fautoresearch-{slug}\u002F`\n- **Required artifact sections:**\n  - `Mission Draft`\n  - `Evaluator Draft`\n  - `Launch Readiness`\n  - `Seed Inputs`\n  - `Confirmation Bridge`\n- **Required launch artifacts under `.omx\u002Fspecs\u002Fautoresearch-{slug}\u002F`:**\n  - `mission.md`\n  - `sandbox.md`\n  - `result.json`\n- **Launch-readiness rule:** mark the draft as **not launch-ready** while the evaluator command still contains placeholder markers such as `\u003C...>`, `TODO`, `TBD`, `REPLACE_ME`, `CHANGEME`, or `your-command-here`\n- **Structured result contract:** `result.json` should point to the draft + mission\u002Fsandbox artifacts and carry the finalized `topic`, `evaluatorCommand`, `keepPolicy`, `slug`, `launchReady`, and `blockedReasons` fields so `omx autoresearch` can consume it directly\n- **Confirmation bridge:** after artifact generation, offer at least `refine further` and `launch`; do not launch detached tmux until the user explicitly confirms `launch`\n- **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\n\n## Phase 5: Execution Bridge\n\nPresent 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, and any residual-risk warnings across the handoff.\n\n### 1. **`$ralplan` (Recommended)**\n- **Input Artifact:** `.omx\u002Fspecs\u002Fdeep-interview-{slug}.md` (optionally accompanied by the transcript\u002Fcontext snapshot for traceability)\n- **Invocation:** `$plan --consensus --direct \u003Cspec-path>`\n- **Consumer Behavior:** Treat the deep-interview spec as the requirements source of truth. Do not repeat the interview by default; refine architecture\u002Ffeasibility around the clarified intent and boundaries instead.\n- **Skipped \u002F Already-Satisfied Stages:** Requirements discovery, ambiguity clarification, and early intent-boundary elicitation\n- **Expected Output:** Canonical planning artifacts under `.omx\u002Fplans\u002F`, especially `prd-*.md` and `test-spec-*.md`\n- **Best When:** Requirements are clear enough to stop interviewing, but architectural validation \u002F consensus planning is still desirable\n- **Next Recommended Step:** Use the approved planning artifacts with `$autopilot`, `$ralph`, or `$team` depending on the desired execution style\n\n### 2. **`$autopilot`**\n- **Input Artifact:** `.omx\u002Fspecs\u002Fdeep-interview-{slug}.md`\n- **Invocation:** `$autopilot \u003Cspec-path>`\n- **Consumer Behavior:** Use the deep-interview spec as the clarified execution brief. Preserve intent, non-goals, decision boundaries, and acceptance criteria as binding context for planning\u002Fexecution.\n- **Skipped \u002F Already-Satisfied Stages:** Initial requirement discovery and ambiguity reduction\n- **Expected Output:** Planning\u002Fexecution progress, QA evidence, and validation artifacts produced by autopilot\n- **Best When:** The clarified spec is already strong enough for direct planning + execution without an additional consensus gate\n- **Next Recommended Step:** Continue through autopilot's execution\u002FQA\u002Fvalidation flow; if coordination-heavy execution emerges, prefer a follow-up `$team` or `$ralph` lane as appropriate\n\n### 3. **`$ralph`**\n- **Input Artifact:** `.omx\u002Fspecs\u002Fdeep-interview-{slug}.md`\n- **Invocation:** `$ralph \u003Cspec-path>`\n- **Consumer Behavior:** Use the spec's acceptance criteria and boundary constraints as the persistence target. Do not reopen requirements discovery unless the user explicitly asks to refine further.\n- **Skipped \u002F Already-Satisfied Stages:** Requirement interview, ambiguity clarification, and initial scope-definition work\n- **Expected Output:** Iterative execution progress and verification evidence tracked against the clarified criteria\n- **Best When:** The task benefits from persistent sequential completion pressure and the user wants execution to keep moving until the criteria are satisfied or a real blocker exists\n- **Next Recommended Step:** Continue Ralph's persistence loop; if work expands into coordination-heavy lanes, hand off to `$team` and keep Ralph for verification continuity\n\n### 4. **`$team`**\n- **Input Artifact:** `.omx\u002Fspecs\u002Fdeep-interview-{slug}.md`\n- **Invocation:** `$team \u003Cspec-path>`\n- **Consumer Behavior:** Treat the spec as shared execution context for coordinated parallel work. Preserve the clarified intent, non-goals, decision boundaries, and acceptance criteria as common lane constraints.\n- **Skipped \u002F Already-Satisfied Stages:** Requirement clarification and early ambiguity reduction\n- **Expected Output:** Coordinated multi-agent execution against the shared spec, with evidence that can later feed a Ralph verification pass when appropriate\n- **Best When:** The task is large, multi-lane, or blocker-sensitive enough to justify coordinated parallel execution instead of a single persistent loop\n- **Next Recommended Step:** Follow the team verification path when the coordinated execution phase finishes; escalate to a separate Ralph loop only when a later persistent verification\u002Ffix owner is still needed\n\n### 5. **Refine further**\n- **Input Artifact:** Existing transcript, context snapshot, and current spec draft\n- **Invocation:** Continue the interview loop\n- **Consumer Behavior:** Re-enter questioning to resolve the highest-leverage remaining uncertainty\n- **Skipped \u002F Already-Satisfied Stages:** None beyond already-captured context\n- **Expected Output:** A lower-ambiguity spec with tighter boundaries and fewer unresolved assumptions\n- **Best When:** Residual ambiguity is still too high, the user wants stronger clarity, or the above-threshold \u002F early-exit warning indicates too much risk to proceed cleanly\n- **Next Recommended Step:** Return to one of the execution handoff contracts above once the spec is sufficiently clarified\n\n**Residual-Risk Rule:** If the interview ended via early exit, hard-cap completion, 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.\n\n**IMPORTANT:** Deep-interview is a requirements mode. On handoff, invoke the selected skill using the contract above. **Do NOT implement directly** inside deep-interview.\n\n\u003C\u002FSteps>\n\n\u003CTool_Usage>\n- Use `explore` for codebase fact gathering\n- Use `request_user_input` \u002F structured user-input tool for each interview round when available\n- If structured question tools are unavailable, use plain-text single-question rounds and keep the same stage order\n- Use `state_write` \u002F `state_read` for resumable mode state\n- Read\u002Fwrite context snapshots under `.omx\u002Fcontext\u002F`\n- Save transcript\u002Fspec artifacts under `.omx\u002Finterviews\u002F` and `.omx\u002Fspecs\u002F`\n\u003C\u002FTool_Usage>\n\n\u003CEscalation_And_Stop_Conditions>\n- User says stop\u002Fcancel\u002Fabort -> persist state and stop\n- Ambiguity stalls for 3 rounds (+\u002F- 0.05) -> force Ontologist mode once\n- Max rounds reached -> proceed with explicit residual-risk warning\n- All dimensions >= 0.9 -> allow early crystallization even before max rounds\n\u003C\u002FEscalation_And_Stop_Conditions>\n\n\u003CFinal_Checklist>\n- [ ] Preflight context snapshot exists under `.omx\u002Fcontext\u002F{slug}-{timestamp}.md`\n- [ ] Ambiguity score shown each round\n- [ ] Intent-first stage priority used before implementation detail\n- [ ] Weakest-dimension targeting used within the active stage\n- [ ] At least one explicit assumption probe happened before crystallization\n- [ ] At least one persistent follow-up \u002F pressure pass deepened a prior answer\n- [ ] Challenge modes triggered at thresholds (when applicable)\n- [ ] Transcript written to `.omx\u002Finterviews\u002F{slug}-{timestamp}.md`\n- [ ] Spec written to `.omx\u002Fspecs\u002Fdeep-interview-{slug}.md`\n- [ ] Brownfield questions use evidence-backed confirmation when applicable\n- [ ] Handoff options provided (`$ralplan`, `$autopilot`, `$ralph`, `$team`)\n- [ ] No direct implementation performed in this mode\n\u003C\u002FFinal_Checklist>\n\n\u003CAdvanced>\n## Suggested Config (optional)\n\n```toml\n[omx.deepInterview]\ndefaultProfile = \"standard\"\nquickThreshold = 0.30\nstandardThreshold = 0.20\ndeepThreshold = 0.15\nquickMaxRounds = 5\nstandardMaxRounds = 12\ndeepMaxRounds = 20\nenableChallengeModes = true\n```\n\n## Resume\n\nIf interrupted, rerun `$deep-interview`. Resume from persisted mode state via `state_read(mode=\"deep-interview\")`.\n\n## Recommended 3-Stage Pipeline\n\n```\ndeep-interview -> ralplan -> autopilot\n```\n\n- Stage 1 (deep-interview): clarity gate\n- Stage 2 (ralplan): feasibility + architecture gate\n- Stage 3 (autopilot): execution + QA + validation gate\n\u003C\u002FAdvanced>\n\nTask: {{ARGUMENTS}}\n","\u003CPurpose>\nDeep Interview is an intent-first Socratic clarification loop before planning or implementation. It turns vague ideas into execution-ready specifications by asking targeted questions about why the user wants a change, how far it should go, what should stay out of scope, and what OMX may decide without confirmation.\n\u003C\u002FPurpose>\n\n\u003CUse_When>\n- The request is broad, ambiguous, or missing concrete acceptance criteria\n- The user says \"deep interview\", \"interview me\", \"ask me everything\", \"don't assume\", or \"ouroboros\"\n- The user wants to avoid misaligned implementation from underspecified requirements\n- You need a requirements artifact before handing off to `ralplan`, `autopilot`, `ralph`, or `team`\n\u003C\u002FUse_When>\n\n\u003CDo_Not_Use_When>\n- The request already has concrete file\u002Fsymbol targets and clear acceptance criteria\n- The user explicitly asks to skip planning\u002Finterview and execute immediately\n- The user asks for lightweight brainstorming only (use `plan` instead)\n- A complete PRD\u002Fplan already exists and execution should start\n\u003C\u002FDo_Not_Use_When>\n\n\u003CWhy_This_Exists>\nExecution 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 the scope should stop, which tradeoffs are unacceptable, and which decisions still require user approval. This workflow applies Socratic pressure + quantitative ambiguity scoring so orchestration modes begin with an explicit, testable, intent-aligned spec.\n\u003C\u002FWhy_This_Exists>\n\n\u003CDepth_Profiles>\n- **Quick (`--quick`)**: fast pre-PRD pass; target threshold `\u003C= 0.30`; max rounds 5\n- **Standard (`--standard`, default)**: full requirement interview; target threshold `\u003C= 0.20`; max rounds 12\n- **Deep (`--deep`)**: high-rigor exploration; target threshold `\u003C= 0.15`; max rounds 20\n- **Autoresearch (`--autoresearch`)**: same interview rigor as Standard, but specialized for `omx autoresearch` launch readiness and `.omx\u002Fspecs\u002F` mission\u002Fsandbox artifact handoff\n\nIf no flag is provided, use **Standard**.\n\n\u003CMode_Flags>\n- **`--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\u002Fspecs\u002F`, and preserve the explicit `refine further` vs `launch` boundary for downstream CLI intake.\n\u003C\u002FMode_Flags>\n\u003C\u002FDepth_Profiles>\n\n\u003CExecution_Policy>\n- Ask ONE question per round (never batch)\n- Ask about intent and boundaries before implementation detail\n- Target the weakest clarity dimension each round after applying the stage-priority rules below\n- Treat every answer as a claim to pressure-test before moving on: the next question should usually demand evidence or examples, expose a hidden assumption, force a tradeoff or boundary, or reframe root cause vs symptom\n- Do not rotate to a new clarity dimension just for coverage when the current answer is still vague; stay on the same thread until one layer deeper, one assumption clearer, or one boundary tighter\n- Before crystallizing, complete at least one explicit pressure pass that revisits an earlier answer with a deeper, assumption-focused, or tradeoff-focused follow-up\n- Gather codebase facts via `explore` before asking user about internals\n- When session guidance enables `USE_OMX_EXPLORE_CMD`, prefer `omx explore` for simple read-only brownfield fact gathering; keep prompts narrow and concrete, and keep ambiguous or non-shell-only investigation on the richer normal path and fall back normally if `omx explore` is unavailable.\n- Always run a preflight context intake before the first interview question\n- Reduce user effort: ask only the highest-leverage unresolved question, and never ask the user for codebase facts that can be discovered directly\n- For brownfield work, prefer evidence-backed confirmation questions such as \"I found X in Y. Should this change follow that pattern?\"\n- In Codex CLI, prefer `request_user_input` when available; if unavailable, fall back to concise plain-text one-question turns\n- Re-score ambiguity after each answer and show progress transparently\n- Do not hand off to execution while ambiguity remains above threshold unless user explicitly opts to proceed with warning\n- Do not crystallize or hand off while `Non-goals` or `Decision Boundaries` remain unresolved, even if the weighted ambiguity threshold is met\n- Treat early exit as a safety valve, not the default success path\n- Persist mode state for resume safety (`state_write` \u002F `state_read`)\n\u003C\u002FExecution_Policy>\n\n\u003CSteps>\n\n## Phase 0: Preflight Context Intake\n\n1. Parse `{{ARGUMENTS}}` and derive a short task slug.\n2. Attempt to load the latest relevant context snapshot from `.omx\u002Fcontext\u002F{slug}-*.md`.\n3. If no snapshot exists, create a minimum context snapshot with:\n   - Task statement\n   - Desired outcome\n   - Stated solution (what the user asked for)\n   - Probable intent hypothesis (why they likely want it)\n   - Known facts\u002Fevidence\n   - Constraints\n   - Unknowns\u002Fopen questions\n   - Decision-boundary unknowns\n   - Likely codebase touchpoints\n4. Save snapshot to `.omx\u002Fcontext\u002F{slug}-{timestamp}.md` (UTC `YYYYMMDDTHHMMSSZ`) and reference it in mode state.\n\n## Phase 1: Initialize\n\n1. Parse `{{ARGUMENTS}}` and depth profile (`--quick|--standard|--deep`).\n2. Detect project context:\n   - Run `explore` to classify **brownfield** (existing codebase target) vs **greenfield**.\n   - For brownfield, collect relevant codebase context before questioning.\n3. Initialize state via `state_write(mode=\"deep-interview\")`:\n\n```json\n{\n  \"active\": true,\n  \"current_phase\": \"deep-interview\",\n  \"state\": {\n    \"interview_id\": \"\u003Cuuid>\",\n    \"profile\": \"quick|standard|deep\",\n    \"type\": \"greenfield|brownfield\",\n    \"initial_idea\": \"\u003Cuser input>\",\n    \"rounds\": [],\n    \"current_ambiguity\": 1.0,\n    \"threshold\": 0.3,\n    \"max_rounds\": 5,\n    \"challenge_modes_used\": [],\n    \"codebase_context\": null,\n    \"current_stage\": \"intent-first\",\n    \"current_focus\": \"intent\",\n    \"context_snapshot_path\": \".omx\u002Fcontext\u002F\u003Cslug>-\u003Ctimestamp>.md\"\n  }\n}\n```\n\n4. Announce kickoff with profile, threshold, and current ambiguity.\n\n## Phase 2: Socratic Interview Loop\n\nRepeat until ambiguity `\u003C= threshold`, the pressure pass is complete, the readiness gates are explicit, the user exits with warning, or max rounds are reached.\n\n### 2a) Generate next question\nUse:\n- Original idea\n- Prior Q&A rounds\n- Current dimension scores\n- Brownfield context (if any)\n- Activated challenge mode injection (Phase 3)\n\nTarget the lowest-scoring dimension, but respect stage priority:\n- **Stage 1 — Intent-first:** Intent, Outcome, Scope, Non-goals, Decision Boundaries\n- **Stage 2 — Feasibility:** Constraints, Success Criteria\n- **Stage 3 — Brownfield grounding:** Context Clarity (brownfield only)\n\nFollow-up pressure ladder after each answer:\n1. Ask for a concrete example, counterexample, or evidence signal behind the latest claim\n2. Probe the hidden assumption, dependency, or belief that makes the claim true\n3. Force a boundary or tradeoff: what would you explicitly not do, defer, or reject?\n4. If the answer still describes symptoms, reframe toward essence \u002F root cause before moving on\n\nPrefer staying on the same thread for multiple rounds when it has the highest leverage. Breadth without pressure is not progress.\n\nDetailed dimensions:\n- Intent Clarity — why the user wants this\n- Outcome Clarity — what end state they want\n- Scope Clarity — how far the change should go\n- Constraint Clarity — technical or business limits that must hold\n- Success Criteria Clarity — how completion will be judged\n- Context Clarity — existing codebase understanding (brownfield only)\n\n`Non-goals` and `Decision Boundaries` are mandatory readiness gates. Ask about them early and keep revisiting them until they are explicit.\n\n### 2b) Ask the question\nUse structured user-input tooling available in the runtime (`AskUserQuestion` \u002F equivalent) and present:\n\n```\nRound {n} | Target: {weakest_dimension} | Ambiguity: {score}%\n\n{question}\n```\n\n### 2c) Score ambiguity\nScore each weighted dimension in `[0.0, 1.0]` with justification + gap.\n\nGreenfield: `ambiguity = 1 - (intent × 0.30 + outcome × 0.25 + scope × 0.20 + constraints × 0.15 + success × 0.10)`\n\nBrownfield: `ambiguity = 1 - (intent × 0.25 + outcome × 0.20 + scope × 0.20 + constraints × 0.15 + success × 0.10 + context × 0.10)`\n\nReadiness gate:\n- `Non-goals` must be explicit\n- `Decision Boundaries` must be explicit\n- A pressure pass must be complete: at least one earlier answer has been revisited with an evidence, assumption, or tradeoff follow-up\n- If either gate is unresolved, or the pressure pass is incomplete, continue interviewing even when weighted ambiguity is below threshold\n\n### 2d) Report progress\nShow weighted breakdown table, readiness-gate status (`Non-goals`, `Decision Boundaries`), and the next focus dimension.\n\n### 2e) Persist state\nAppend round result and updated scores via `state_write`.\n\n### 2f) Round controls\n- Do not offer early exit before the first explicit assumption probe and one persistent follow-up have happened\n- Round 4+: allow explicit early exit with risk warning\n- Soft warning at profile midpoint (e.g., round 3\u002F6\u002F10 depending on profile)\n- Hard cap at profile `max_rounds`\n\n## Phase 3: Challenge Modes (assumption stress tests)\n\nUse each mode once when applicable. These are normal escalation tools, not rare rescue moves:\n\n- **Contrarian** (round 2+ or immediately when an answer rests on an untested assumption): challenge core assumptions\n- **Simplifier** (round 4+ or when scope expands faster than outcome clarity): probe minimal viable scope\n- **Ontologist** (round 5+ and ambiguity > 0.25, or when the user keeps describing symptoms): ask for essence-level reframing\n\nTrack used modes in state to prevent repetition.\n\n## Phase 4: Crystallize Artifacts\n\nWhen threshold is met (or user exits with warning \u002F hard cap):\n\n1. Write interview transcript summary to:\n   - `.omx\u002Finterviews\u002F{slug}-{timestamp}.md`  \n     (kept for ralph PRD compatibility)\n2. Write execution-ready spec to:\n   - `.omx\u002Fspecs\u002Fdeep-interview-{slug}.md`\n\nSpec should include:\n- Metadata (profile, rounds, final ambiguity, threshold, context type)\n- Context snapshot reference\u002Fpath (for ralplan\u002Fteam reuse)\n- Clarity breakdown table\n- Intent (why the user wants this)\n- Desired Outcome\n- In-Scope\n- Out-of-Scope \u002F Non-goals\n- Decision Boundaries (what OMX may decide without confirmation)\n- Constraints\n- Testable acceptance criteria\n- Assumptions exposed + resolutions\n- Pressure-pass findings (which answer was revisited, and what changed)\n- Brownfield evidence vs inference notes for any repository-grounded confirmation questions\n- Technical context findings\n- Full or condensed transcript\n\n### Autoresearch specialization\n\nWhen 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.\n\n- **Accepted seed inputs:** `topic`, `evaluator`, `keep-policy`, `slug`, existing mission draft text, and prior evaluator examples\u002Ftemplates\n- **Required interview focus:** mission clarity, evaluator readiness, keep policy, slug\u002Fsession naming, and whether the draft is ready to launch now or should refine further\n- **Canonical artifact path:** `.omx\u002Fspecs\u002Fdeep-interview-autoresearch-{slug}.md`\n- **Launch artifact bundle:** `.omx\u002Fspecs\u002Fautoresearch-{slug}\u002Fmission.md`, `.omx\u002Fspecs\u002Fautoresearch-{slug}\u002Fsandbox.md`, and `.omx\u002Fspecs\u002Fautoresearch-{slug}\u002Fresult.json`\n- **Launch artifact directory:** `.omx\u002Fspecs\u002Fautoresearch-{slug}\u002F`\n- **Required artifact sections:**\n  - `Mission Draft`\n  - `Evaluator Draft`\n  - `Launch Readiness`\n  - `Seed Inputs`\n  - `Confirmation Bridge`\n- **Required launch artifacts under `.omx\u002Fspecs\u002Fautoresearch-{slug}\u002F`:**\n  - `mission.md`\n  - `sandbox.md`\n  - `result.json`\n- **Launch-readiness rule:** mark the draft as **not launch-ready** while the evaluator command still contains placeholder markers such as `\u003C...>`, `TODO`, `TBD`, `REPLACE_ME`, `CHANGEME`, or `your-command-here`\n- **Structured result contract:** `result.json` should point to the draft + mission\u002Fsandbox artifacts and carry the finalized `topic`, `evaluatorCommand`, `keepPolicy`, `slug`, `launchReady`, and `blockedReasons` fields so `omx autoresearch` can consume it directly\n- **Confirmation bridge:** after artifact generation, offer at least `refine further` and `launch`; do not launch detached tmux until the user explicitly confirms `launch`\n- **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\n\n## Phase 5: Execution Bridge\n\nPresent 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, and any residual-risk warnings across the handoff.\n\n### 1. **`$ralplan` (Recommended)**\n- **Input Artifact:** `.omx\u002Fspecs\u002Fdeep-interview-{slug}.md` (optionally accompanied by the transcript\u002Fcontext snapshot for traceability)\n- **Invocation:** `$plan --consensus --direct \u003Cspec-path>`\n- **Consumer Behavior:** Treat the deep-interview spec as the requirements source of truth. Do not repeat the interview by default; refine architecture\u002Ffeasibility around the clarified intent and boundaries instead.\n- **Skipped \u002F Already-Satisfied Stages:** Requirements discovery, ambiguity clarification, and early intent-boundary elicitation\n- **Expected Output:** Canonical planning artifacts under `.omx\u002Fplans\u002F`, especially `prd-*.md` and `test-spec-*.md`\n- **Best When:** Requirements are clear enough to stop interviewing, but architectural validation \u002F consensus planning is still desirable\n- **Next Recommended Step:** Use the approved planning artifacts with `$autopilot`, `$ralph`, or `$team` depending on the desired execution style\n\n### 2. **`$autopilot`**\n- **Input Artifact:** `.omx\u002Fspecs\u002Fdeep-interview-{slug}.md`\n- **Invocation:** `$autopilot \u003Cspec-path>`\n- **Consumer Behavior:** Use the deep-interview spec as the clarified execution brief. Preserve intent, non-goals, decision boundaries, and acceptance criteria as binding context for planning\u002Fexecution.\n- **Skipped \u002F Already-Satisfied Stages:** Initial requirement discovery and ambiguity reduction\n- **Expected Output:** Planning\u002Fexecution progress, QA evidence, and validation artifacts produced by autopilot\n- **Best When:** The clarified spec is already strong enough for direct planning + execution without an additional consensus gate\n- **Next Recommended Step:** Continue through autopilot's execution\u002FQA\u002Fvalidation flow; if coordination-heavy execution emerges, prefer a follow-up `$team` or `$ralph` lane as appropriate\n\n### 3. **`$ralph`**\n- **Input Artifact:** `.omx\u002Fspecs\u002Fdeep-interview-{slug}.md`\n- **Invocation:** `$ralph \u003Cspec-path>`\n- **Consumer Behavior:** Use the spec's acceptance criteria and boundary constraints as the persistence target. Do not reopen requirements discovery unless the user explicitly asks to refine further.\n- **Skipped \u002F Already-Satisfied Stages:** Requirement interview, ambiguity clarification, and initial scope-definition work\n- **Expected Output:** Iterative execution progress and verification evidence tracked against the clarified criteria\n- **Best When:** The task benefits from persistent sequential completion pressure and the user wants execution to keep moving until the criteria are satisfied or a real blocker exists\n- **Next Recommended Step:** Continue Ralph's persistence loop; if work expands into coordination-heavy lanes, hand off to `$team` and keep Ralph for verification continuity\n\n### 4. **`$team`**\n- **Input Artifact:** `.omx\u002Fspecs\u002Fdeep-interview-{slug}.md`\n- **Invocation:** `$team \u003Cspec-path>`\n- **Consumer Behavior:** Treat the spec as shared execution context for coordinated parallel work. Preserve the clarified intent, non-goals, decision boundaries, and acceptance criteria as common lane constraints.\n- **Skipped \u002F Already-Satisfied Stages:** Requirement clarification and early ambiguity reduction\n- **Expected Output:** Coordinated multi-agent execution against the shared spec, with evidence that can later feed a Ralph verification pass when appropriate\n- **Best When:** The task is large, multi-lane, or blocker-sensitive enough to justify coordinated parallel execution instead of a single persistent loop\n- **Next Recommended Step:** Follow the team verification path when the coordinated execution phase finishes; escalate to a separate Ralph loop only when a later persistent verification\u002Ffix owner is still needed\n\n### 5. **Refine further**\n- **Input Artifact:** Existing transcript, context snapshot, and current spec draft\n- **Invocation:** Continue the interview loop\n- **Consumer Behavior:** Re-enter questioning to resolve the highest-leverage remaining uncertainty\n- **Skipped \u002F Already-Satisfied Stages:** None beyond already-captured context\n- **Expected Output:** A lower-ambiguity spec with tighter boundaries and fewer unresolved assumptions\n- **Best When:** Residual ambiguity is still too high, the user wants stronger clarity, or the above-threshold \u002F early-exit warning indicates too much risk to proceed cleanly\n- **Next Recommended Step:** Return to one of the execution handoff contracts above once the spec is sufficiently clarified\n\n**Residual-Risk Rule:** If the interview ended via early exit, hard-cap completion, 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.\n\n**IMPORTANT:** Deep-interview is a requirements mode. On handoff, invoke the selected skill using the contract above. **Do NOT implement directly** inside deep-interview.\n\n\u003C\u002FSteps>\n\n\u003CTool_Usage>\n- Use `explore` for codebase fact gathering\n- Use `request_user_input` \u002F structured user-input tool for each interview round when available\n- If structured question tools are unavailable, use plain-text single-question rounds and keep the same stage order\n- Use `state_write` \u002F `state_read` for resumable mode state\n- Read\u002Fwrite context snapshots under `.omx\u002Fcontext\u002F`\n- Save transcript\u002Fspec artifacts under `.omx\u002Finterviews\u002F` and `.omx\u002Fspecs\u002F`\n\u003C\u002FTool_Usage>\n\n\u003CEscalation_And_Stop_Conditions>\n- User says stop\u002Fcancel\u002Fabort -> persist state and stop\n- Ambiguity stalls for 3 rounds (+\u002F- 0.05) -> force Ontologist mode once\n- Max rounds reached -> proceed with explicit residual-risk warning\n- All dimensions >= 0.9 -> allow early crystallization even before max rounds\n\u003C\u002FEscalation_And_Stop_Conditions>\n\n\u003CFinal_Checklist>\n- [ ] Preflight context snapshot exists under `.omx\u002Fcontext\u002F{slug}-{timestamp}.md`\n- [ ] Ambiguity score shown each round\n- [ ] Intent-first stage priority used before implementation detail\n- [ ] Weakest-dimension targeting used within the active stage\n- [ ] At least one explicit assumption probe happened before crystallization\n- [ ] At least one persistent follow-up \u002F pressure pass deepened a prior answer\n- [ ] Challenge modes triggered at thresholds (when applicable)\n- [ ] Transcript written to `.omx\u002Finterviews\u002F{slug}-{timestamp}.md`\n- [ ] Spec written to `.omx\u002Fspecs\u002Fdeep-interview-{slug}.md`\n- [ ] Brownfield questions use evidence-backed confirmation when applicable\n- [ ] Handoff options provided (`$ralplan`, `$autopilot`, `$ralph`, `$team`)\n- [ ] No direct implementation performed in this mode\n\u003C\u002FFinal_Checklist>\n\n\u003CAdvanced>\n## Suggested Config (optional)\n\n```toml\n[omx.deepInterview]\ndefaultProfile = \"standard\"\nquickThreshold = 0.30\nstandardThreshold = 0.20\ndeepThreshold = 0.15\nquickMaxRounds = 5\nstandardMaxRounds = 12\ndeepMaxRounds = 20\nenableChallengeModes = true\n```\n\n## Resume\n\nIf interrupted, rerun `$deep-interview`. Resume from persisted mode state via `state_read(mode=\"deep-interview\")`.\n\n## Recommended 3-Stage Pipeline\n\n```\ndeep-interview -> ralplan -> autopilot\n```\n\n- Stage 1 (deep-interview): clarity gate\n- Stage 2 (ralplan): feasibility + architecture gate\n- Stage 3 (autopilot): execution + QA + validation gate\n\u003C\u002FAdvanced>\n\nTask: {{ARGUMENTS}}\n",{"name":5,"description":7,"argument-hint":43},"[--quick|--standard|--deep] [--autoresearch] \u003Cidea or vague description>","main","7a38d8e7073e61c16eda85681cb32fb68a8657a5","skills-store\u002Fcodex\u002Fdeep-interview","https:\u002F\u002Fgithub.com\u002Fsapsapshen\u002Fai-memory-router","https:\u002F\u002Fgithub.com\u002Fsapsapshen","2026-04-14 21:12:12",{"source":8,"skillName":5,"commands":51,"prompt":61,"zipAvailable":62},[52,55,58],{"tool":53,"command":54},"npx","npx skills add sapsapshen\u002Fai-memory-router --skill deep-interview",{"tool":56,"command":57},"bunx","bunx skills add sapsapshen\u002Fai-memory-router --skill deep-interview",{"tool":59,"command":60},"pnpm","pnpm dlx skills add sapsapshen\u002Fai-memory-router --skill deep-interview","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fsapsapshen\u002Fai-memory-router\u002Fblob\u002Fmain\u002Fskills-store\u002Fcodex\u002Fdeep-interview\u002FSKILL.md",true,[],[65,86,112,122,135,154],{"skillNo":66,"name":67,"nameZh":6,"description":68,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":69,"categories":70,"keywords":74,"publishedAt":38},"01M71ATQRKG48SH06FQ697T5G9","wechat-search","Search WeChat Official Account articles using OpenClaw's web search and fetch capabilities with compliance-focused design.","https:\u002F\u002Fgithub.com\u002Fsapsapshen\u002Fai-memory-router\u002Fblob\u002Fmain\u002Fskills-store\u002Fopenclaw\u002Fwechat-search-release\u002FSKILL.md",[71],{"categoryNo":72,"categoryName":73,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000037","律师与法务",[75,76,77,78,79,80,81,82,83,84,85,31],"wechat search","wechat","search","capabilities","openclaw","design","web search","compliance","web","official","fetch",{"skillNo":87,"name":88,"nameZh":6,"description":89,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":90,"categories":91,"keywords":92,"publishedAt":38},"01M71ATNAVGZB35PFYM2GC5N00","trend-tap","Real-time trending topics aggregator across 7 platforms (X\u002FTwitter, Reddit, Google Trends, Hacker News, Zhihu, Bilibili, Weibo). Trigger: when user says 'trend', 'trends', 'trend tap', '热点', '热搜', or asks what is trending\u002Fhot. Do NOT use web_search — this skill already fetches live data from all platforms with zero API keys.","https:\u002F\u002Fgithub.com\u002Fsapsapshen\u002Fai-memory-router\u002Fblob\u002Fmain\u002Fskills-store\u002Fopenclaw\u002Ftrend-tap\u002FSKILL.md",[],[93,94,95,96,97,98,77,99,100,101,102,103,104,105,106,107,108,109,110,111],"trend","trend tap","tap","api keys","Bash","time","trending","hacker","aggregator","do","when","brew","live","data","google","install","read","across","api",{"skillNo":113,"name":114,"nameZh":6,"description":115,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":116,"categories":117,"keywords":118,"publishedAt":38},"01M71ATJ9AM5KM15AA8PS302EB","trend-radar","Real-time trending topics aggregator across 7 platforms (X\u002FTwitter, Reddit, Google Trends, Hacker News, Zhihu, Bilibili, Weibo). Trigger: when user says 'trend', 'trends', 'trend pulse', '热点', '热搜', or asks what is trending\u002Fhot. Do NOT use web_search — this skill already fetches live data from all platforms with zero API keys.","https:\u002F\u002Fgithub.com\u002Fsapsapshen\u002Fai-memory-router\u002Fblob\u002Fmain\u002Fskills-store\u002Fopenclaw\u002Ftrend-radar\u002FSKILL.md",[],[119,120,93,104,105,106,107,97,77,109,121,110,111,103,101,100,99,108,98,96],"trend radar","radar","pulse",{"skillNo":123,"name":124,"nameZh":6,"description":125,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":126,"categories":127,"keywords":128,"publishedAt":38},"01M71ATGF095N3EJM9G8SD0BB5","tech-news-daily","每日科技新闻汇——从全球多个 RSS 源抓取最新科技新闻，翻译（英→中）、去重、排版成每日简报。当用户询问科技新闻、科技新鲜事、每日科技、技术动态、Daily Tech News 或类似表达时触发此技能。","https:\u002F\u002Fgithub.com\u002Fsapsapshen\u002Fai-memory-router\u002Fblob\u002Fmain\u002Fskills-store\u002Fopenclaw\u002Ftech-news-daily\u002FSKILL.md",[],[129,130,131,132,133,134],"news","tech","tech news daily","daily","rss","翻译",{"skillNo":136,"name":137,"nameZh":6,"description":138,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":139,"categories":140,"keywords":146,"publishedAt":38},"01M71ATFAEAMQ17M70NQNY7SR8","summarize","Summarize URLs or files with the summarize CLI (web, PDFs, images, audio, YouTube).","https:\u002F\u002Fgithub.com\u002Fsapsapshen\u002Fai-memory-router\u002Fblob\u002Fmain\u002Fskills-store\u002Fopenclaw\u002Fsummarize\u002FSKILL.md",[141],{"categoryNo":142,"categoryName":143,"taxonomyType":144,"taxonomyTypeDesc":145},"01JBSEEDCAT000000000000021","资料检索与研究","SCENARIO","使用场景",[137,83,147,148,149,31,104,150,151,152,95,153,108],"Audio","cli","youtube","images","https","files","pdfs",{"skillNo":155,"name":156,"nameZh":6,"description":157,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":158,"categories":159,"keywords":160,"publishedAt":38},"01M71ATDNS3R0M4H936PACQAWZ","sonoscli","Control Sonos speakers (discover\u002Fstatus\u002Fplay\u002Fvolume\u002Fgroup).","https:\u002F\u002Fgithub.com\u002Fsapsapshen\u002Fai-memory-router\u002Fblob\u002Fmain\u002Fskills-store\u002Fopenclaw\u002Fsonoscli\u002FSKILL.md",[],[156,161,162,163,108,164,151,165,166,167,168,169],"status","play","go","latest","github","discover","control","cmd","volume"]