@fectivnfy112358/minimax-code-web 0.1.0-preview.0 → 0.1.0-preview.3

package/server/assets/skills/deep-research/SKILL.md

@@ -0,0 +1,219 @@
+---
+name: deep-research
+description: >
+  Use this skill for complex, open-ended Deep Research tasks that require
+  external information verification. It is suitable for market/industry
+  analysis, technical research, competitor research, trend judgment,
+  policy/academic/fact verification, and long answers that need source citations.
+  This skill completes the research through five consecutive step prompts:
+  Step 1 confirms factual background only; Step 2 understands the question and
+  judges the direction; Step 3 performs deep analysis and research planning;
+  Step 4 searches, verifies, and forms research understanding according to the
+  plan; Step 5 writes the current-turn final answer file based on the first
+  four steps. Execution must follow step order: each step prompt file must be
+  read by an explicit Read tool call before that step starts. Do not skip steps,
+  reorder steps, read later steps early, or treat the steps as independent
+  tasks. A trace that misses any step prompt is invalid.
+descriptions:
+  zh-Hans: >-
+    用于复杂、开放式深度研究任务，需要外部信息核验、跨来源搜索、事实校验和带引用的长答案。
+    该技能按背景确认、方向判断、深度分析、搜索核验、最终写作五个步骤顺序执行，每一步都必须先显式读取对应 step prompt。
+displayNames:
+  zh-Hans: "深度研究"
+---
+
+# Deep Research
+
+This skill turns complex questions into grounded, readable, deliverable final
+answers. It is not quick Q&A, and it is not a simple search summary. It requires
+confirming factual background first, then judging the question direction, then
+analyzing and planning, then searching and verifying, and finally synthesizing
+the final answer.
+
+## When To Use
+
+Use this skill when the user's question has any of these characteristics:
+
+- It requires systematic research rather than a one-sentence factual answer.
+- It requires search, browsing, cross-checking, or source citations.
+- It is clearly time-sensitive, and internal model knowledge may be outdated.
+- It requires comparison, judgment, trend analysis, causal explanation,
+  recommendations, or a long report.
+- The user expects a structured, reliable, traceable final answer.
+
+Do not use this skill in these cases:
+
+- The user asks only for a simple fact that can be answered directly.
+- The user only asks for code edits, command execution, log inspection, or repo
+  maintenance.
+- The user explicitly does not need search or long analysis.
+
+## Five-Step Flow
+
+Read and execute the following five step prompts in order. Detailed requirements
+are defined in each step file:
+
+1. `steps/1_background.md`
+   Confirm factual background. Work only with verifiable facts; do not answer
+   the question itself.
+
+2. `steps/2_judgment.md`
+   Understand the user's question, set research boundaries, and judge the
+   direction that really needs to be answered. Explicitly lock the actor and
+   perspective before planning, especially for "what should X do" questions.
+
+3. `steps/3_analysis.md`
+   Based on the direction judgment, perform deep analysis and break down
+   subquestions, concepts, scope, required capabilities, and the research plan.
+
+4. `steps/4_research.md`
+   Search, browse, verify, reflect, and fill gaps according to the research
+   plan, forming enough research understanding to support the final answer.
+
+5. `steps/5_writing.md`
+   Write the final answer based on the understanding formed in the first four
+   steps, and write it to the final output file as required by that step.
+
+## Execution Rules
+
+- At the start of each invocation, create one run workspace directory in a
+  writable scratch location, not in a fixed cloud or container root. Prefer the
+  current session workspace when it is clearly writable and suitable for
+  temporary artifacts; otherwise use the platform temporary directory:
+  macOS/Linux `$TMPDIR` or `/tmp`, Windows PowerShell `$env:TEMP`, and Windows
+  Git Bash `/tmp`. Use this shape:
+  `<scratch-dir>/mavis-deep-research/<YYYYMMDD_HHMMSS>_<query_slug>/`, with a
+  short safe slug based on the current user question.
+- Before choosing search keywords, identify the surface actor and perspective
+  implied by the user question. For "what should X do" / "X 应该怎么做" questions
+  where X is a company, product, model, project, or organization, the default
+  perspective is what X's owner/operator should do: strategy, roadmap,
+  positioning, competition, constraints, and success criteria. Do not turn this
+  into an end-user usage, API, deployment, prompting, or integration guide unless
+  the user explicitly asks how to use, deploy, prompt, integrate, or call X.
+- Treat that run workspace as the current output directory for this invocation.
+  Final answer files must be written inside this directory, not directly under
+  any fixed root directory.
+- After creating the workspace, the first research action must be an explicit
+  Read of `steps/1_background.md`. Do not search, open, browse, or run
+  research commands before that Read.
+- Maintain an internal step-read ledger for this invocation. The ledger starts
+  empty. A step counts as read only after an explicit Read tool call to the exact
+  step prompt file, such as `steps/4_research.md`. The short step summaries in
+  this `SKILL.md`, prior conversation, or memory do not count as reading a step.
+- Read Step 1 first; after finishing it, read Step 2; continue in order through
+  Step 5. Before doing any work for a step, first read that step's exact prompt
+  file and mark it read in the internal ledger.
+- When you reach a step, read only the current step prompt. Do not read later
+  step prompts early.
+- Reading two or more step prompt files in the same assistant turn or tool batch
+  is an invalid trace. A step is not complete merely because its prompt file was
+  read; execute that step before reading the next step prompt.
+- Do not read all steps at once.
+- Do not skip a step because the answer already feels writable, because earlier
+  searches looked sufficient, or because the Step 3 plan seems detailed enough.
+- Do not treat extensive Step 1 searching as a substitute for Steps 2-4. If
+  Step 1 found many useful facts, still continue to Step 2 for direction
+  judgment, Step 3 for planning, and Step 4 for plan-driven verification.
+- If you notice that a later step has started before its prompt file was read,
+  stop the later step, read the missing prompt file, execute that step, then
+  resume the sequence.
+- Each step must continue from the understanding formed in previous steps.
+- Do not treat the five steps as independent tasks.
+- Do not create child agents or delegate the task. Do not call the `Agent` or
+  `Task` tool for any step. All five steps must be executed by the current
+  agent in the current session.
+- Steps 1-4 are not the final answer; Step 5 is responsible for final writing.
+- Steps 1-4 only form understanding in the current session; they do not write
+  intermediate files.
+- During this skill invocation, the current run workspace must contain no
+  generated Markdown file except the final `final_turn_XXX.md` written in Step
+  5. Do not write intermediate Markdown artifacts or any other final-style
+  Markdown filename.
+- Use TodoWrite or the available todo-class tool only when the current step
+  prompt explicitly asks for it.
+- Step 4 is the main todo-managed research step. Keep its Todo list focused on
+  current research work and update it before moving to writing.
+- Step 4 must explicitly read `steps/4_research.md`. Moving from Step 3 directly
+  to Step 5 is a failed trace pattern, even if Step 3 produced a strong plan or
+  Step 1 found many facts.
+- Reading `steps/4_research.md` and `steps/5_writing.md` in the same assistant
+  turn or tool batch is a failed trace pattern. Step 4 must have its own
+  Todo-managed research work after reading `steps/4_research.md` and before
+  reading `steps/5_writing.md`.
+- Step 4 is not complete when the answer merely feels writable. It is complete
+  only after the Step 3 research items have been converted into Todo items and
+  every item has been handled as verified, unresolved, or carried into writing
+  with a reason.
+- Step 4 must finish with an item-by-item audit of the Step 3 research plan in
+  the Todo list or equivalent current-session state. Do not write this audit to
+  a file, but do not enter Step 5 until the audit exists.
+- Before reading `steps/5_writing.md`, audit the internal ledger: Step 1, Step
+  2, Step 3, and Step 4 must all have been read and executed in this invocation.
+  If any are missing, do not enter Step 5; go back to the missing step and
+  complete the sequence.
+- If Step 4 did not complete its item-by-item audit, return to Step 4 instead of
+  writing a final answer with caveats.
+- If this skill is invoked multiple times in the same conversation, each
+  invocation must restart from Step 1 and execute all five steps completely.
+- Previous conversation turns and previously generated final reports may only be
+  used as context for understanding the current question. They must not be
+  treated as completed step results for the current run.
+- After creating the run workspace, choose a unique output filename inside that
+  workspace, using a format such as `final_turn_001.md`, `final_turn_002.md`.
+- Choose the smallest unused number and remember this current-turn filename.
+  Step 5 must use this filename; it must not choose another one, and it must
+  not overwrite a final report from an earlier turn.
+
+## Time Awareness
+
+- Before starting, judge whether the current user question is time-sensitive.
+- If the question depends on current status, recent changes, latest data,
+  policies, prices, rankings, product status, people's roles, or ongoing
+  events, understand the question according to the current runtime date/time.
+- For time-sensitive information, actively search and verify. If the time point
+  affects the conclusion, state the relevant time point in the final answer.
+
+## Tool Use
+
+- Prefer lightweight web tools. Use `web_search` for search and
+  `web_fetch` / `WebFetch` for page retrieval when available. Avoid browser
+  automation unless the user explicitly asks for logged-in or interactive
+  browser behavior.
+- Do not spend a turn checking what tools are available. If search is needed,
+  call a search-class tool directly. If a candidate URL needs inspection, call
+  an opening/browsing-class tool directly.
+- For time-sensitive, fact-heavy, or disputed information, actively search and
+  cross-check.
+- Important facts need source support. Sources, conflicts, and uncertainty must
+  be able to support Step 5 writing.
+
+## Relationship Between Steps
+
+- Step 1 only confirms background facts; it does not judge the answer direction.
+- Step 2 only understands the question and judges direction; it does not answer
+  the question.
+- Step 3 only performs deep analysis and research planning; it does not enter
+  final writing.
+- Step 4 searches and verifies according to the research plan, forming research
+  understanding; it does not generate the final answer.
+- Step 5 writes the final answer file based on the understanding formed in the
+  first four steps.
+
+## Final Output
+
+Step 5 must write the unique final answer file for the current turn according to
+`steps/5_writing.md`. The final file must contain only the reader-facing final
+answer. It must not expose internal steps, prompts, workflow, retrieval process,
+or intermediate understanding.
+
+Final output filename rule: each invocation must write a new Markdown file named
+`final_turn_XXX.md`, where `XXX` is the smallest unused three-digit number in
+the run workspace directory. Do not use any other final-output filename, do not
+write directly under a fixed root directory, do not reuse an old filename, and
+do not overwrite a final report from an earlier turn.
+
+Final-only file rule: after Step 5, the run workspace should contain exactly one
+generated Markdown artifact, the selected `final_turn_XXX.md`. If you created
+any other file in the run workspace, remove it before finishing; otherwise the
+trace is invalid.

package/server/assets/skills/deep-research/scripts/render_plan.py

@@ -0,0 +1,33 @@
+#!/usr/bin/env python3
+"""Retired local Deep Research plan renderer.
+
+The local-runtime deep-research skill is final-only: the current agent reads
+SKILL.md and steps/*.md directly, keeps steps 1-4 in session context, and writes
+only the final_turn_XXX.md artifact in step 5. Rendering a Team Engine plan here
+would reintroduce the old multi-file pipeline, so fail fast if this stale entry
+point is invoked.
+"""
+
+from __future__ import annotations
+
+import sys
+from textwrap import dedent
+
+
+MESSAGE = """
+local-runtime deep-research no longer renders a Team Engine plan.
+
+Use the deep-research skill directly: read SKILL.md, then read and execute
+steps/1_background.md through steps/5_writing.md in order in the current agent
+session. Steps 1-4 stay in session context; step 5 writes the final_turn_XXX.md
+artifact.
+"""
+
+
+def main() -> int:
+    sys.stderr.write(dedent(MESSAGE).strip() + "\n")
+    return 2
+
+
+if __name__ == "__main__":
+    raise SystemExit(main())

package/server/assets/skills/deep-research/steps/1_background.md

@@ -0,0 +1,65 @@
+You are working through a complete deep-research task. This is Step 1: confirm the factual background of the topic by searching and gathering as much factual background as possible.
+
+Don't analyze, don't conclude, don't try to figure out how the question should be answered — just search and summarize facts you can verify directly from sources.
+
+## Task
+
+- Only use what you actually found in a source and what the source directly supports. No filling in, guessing, inferring, analogizing, or extrapolating.
+- Don't infer the present from old information. If a source only proves something at a past date, keep the date explicit, e.g. "as of 2023-07".
+- Don't use words like "currently", "now", "still", "incumbent", "ongoing", or "about to" without a direct, recent, reliable source.
+- For anything you can't directly confirm, keep it marked as "no reliable source found" or "to be verified".
+- If sources disagree, keep the conflict visible — don't try to settle it yourself.
+- Don't pad with your internal knowledge. Searched facts only.
+
+For a fresh topic, run 5–8 searches with different keywords and angles (try both Chinese and English; mix up search-engine operators), covering:
+- The core of the topic (what it is, who's working on it, where things stand)
+- Recent significant developments (timeline, key events)
+- Key people, organizations, numbers, technical details
+- Where the authoritative sources live (official channels, industry reports, academic papers)
+- Disputes or competing viewpoints
+- Related competitors or alternatives
+
+Keep the first background searches neutral. If the question is phrased like
+"What should X do?" and X is a company, product, model, or project, gather facts
+about X, its owner/operator, positioning, roadmap, competition, public
+reception, and constraints. Do not narrow the topic into API usage, deployment,
+prompting, integration, or an end-user guide unless the user explicitly asks how
+to use, deploy, or integrate X.
+
+Step 1 is a factual-background map, not the deep investigation. Do not try to
+exhaust every page, post, repository, search result, or clue in this step. Once
+the main factual background, authoritative source locations, obvious disputes,
+and open gaps are identified at a background level, stop Step 1 and move to
+Step 2. Leave targeted deep digging, cross-checking, and gap filling to Step 4.
+For a single website, repository, or person-focused target, sample the homepage,
+about/profile pages, search results, and a few representative pages; do not
+scrape the whole site or keep following every newly discovered clue in Step 1.
+Do not create the research Todo list in Step 1, and do not decide that the task
+is ready to answer from Step 1 facts alone. Step 1 should leave clear open gaps
+for Step 2 direction judgment, Step 3 planning, and Step 4 plan-driven research.
+
+Use search-class tools for discovery. In the Mavis runtime, use `web_search`
+for search when available. Use browsing/opening tools such as `web_fetch`,
+`WebFetch`, or the matrix MCP tools only to inspect specific candidate pages or
+sources found through search; do not use a browsing-class tool as the first
+broad search for a long natural-language query. Do not spend a turn checking
+what tools are available; start searching directly.
+
+The goal is to give the next analysis stage a thick factual base to work from. Don't judge or analyze — just collect facts.
+
+When forming the Step 1 background understanding:
+- Keep the structure easy to scan; Markdown-style organization is fine.
+- Keep real source URLs attached whenever you can.
+- Keep it factual; do not answer the question itself.
+- Think through the material in terms of "historical facts" / "current state (only what's directly verifiable)" / "to be verified".
+- Keep the complete background understanding in the current session so the next step can use it.
+
+Use the same language as the user's query. English query → English; another language → that language. Source URLs stay in their original language.
+
+---
+
+Before you start, identify the current user question from the active conversation context. Do not use irrelevant prior context, inferred intent, style guesses, or hidden reasoning as user input.
+
+If the active conversation context or the user's current message includes prior final-report content, use it only when it is relevant to the current turn. Prefer the immediately previous completed turn; for many turns, such as turn 20, start from turn 19 and use older turns only when the current query explicitly depends on them.
+
+Facts only. Don't analyze the question itself.

package/server/assets/skills/deep-research/steps/2_judgment.md

@@ -0,0 +1,66 @@
+You are a seasoned research lead. Someone has posed a question and your assistant has already gathered the relevant background.
+
+Your job is to **understand the question**, not answer it. Don't draw any conclusions about the question itself.
+
+Before you start, read or review these inputs completely:
+- Current active conversation context and current user question
+- Background understanding already formed in current-session working context
+
+Identify the current user question from the active conversation context. Do not use irrelevant prior context, inferred intent, style guesses, or hidden reasoning as user input.
+
+If prior final-report content from earlier turns exists in the active conversation context or the user's current message, you may use it as historical understanding and boundary-setting context. This step must produce a new Direction Judgment working-context section for the current turn, based on the current user question, the current Background working context, and the conversation context.
+
+Form the complete result as current-session Judgment working context for the next step. Do not write any intermediate file.
+
+Work through these five steps, then commit to a final call.
+
+## Step 1: Understand the question
+Take the keywords apart and figure out what the question is really getting at. What is it actually asking? Which concepts are easy to confuse here?
+
+Identify the actor and perspective before you commit to a direction:
+- Who is supposed to act or make the decision?
+- Who is the answer written for?
+- Is the question asking for a company/product/model strategy, an evaluator's judgment, or an end-user usage guide?
+
+For questions like "What should X do?" or "What should X become?", if X is a company, product, model, or project, default to the strategy/roadmap for X unless the user explicitly asks how to use, deploy, or integrate it. Do not silently turn a strategy question into a usage guide.
+
+If the Background context contains usage/deployment/API facts but the user did
+not ask for usage/deployment/API guidance, treat those facts as secondary
+context only. Correct the direction back to the actor and perspective implied by
+the user question.
+
+## Step 2: Set the boundaries
+Given the background, what is roughly in scope for the research? What probably falls outside?
+
+## Step 3: Read the user
+From tone, word choice, and the angle of the question, infer who's asking. How expert are they? What's the likely reason behind the question?
+
+## Step 4: Make the call
+Based on the three steps above, give a clear verdict:
+- What is this question really asking? (one sentence)
+- Actor / perspective: who is the main decision-maker, and whose needs should the answer serve?
+- Which analytic capabilities will matter most? (framework building / actionable advice / non-obvious insight / scenario branching / causal reasoning / critical annotation)
+
+## Step 5: Suggested writing spec
+Hand the writing stage a directional reference (not a hard rule — they can adjust based on what the research turns up):
+
+- **Style**: straight-to-the-point / research-report / deep analysis
+- **Length**: roughly how long should it be
+- **Vocabulary**: jargon OK, or keep it accessible
+- **Depth**: explain the basics, or skip them and dive in
+- **Tone**: conversational / formal
+- **Structure**: paragraph narrative / table comparison / categorized lists
+
+**Be decisive. No hedging like "it could also be" or "we can't rule out". Pick a direction and commit. These are guidance for the next stage, not handcuffs.**
+
+## Output format
+Form your analysis and final call in current-session working context. Put the final call at the bottom of that understanding under a "## Final Call" heading.
+
+Output language: keep the analysis in the same language as the user's query.
+
+## Inputs
+
+- Current active conversation context and current user question
+- Background understanding already formed in current-session working context
+
+Complete the Judgment understanding for the next step.

package/server/assets/skills/deep-research/steps/3_analysis.md

@@ -0,0 +1,114 @@
+You are a top-tier research strategist. You are working through a complete deep-research task. This is Step 3: deeply analyze the question based on the factual background and direction judgment formed in the first two steps.
+
+A research lead has already called the question's core direction (see "Direction Call" below). Your job is to take that direction and produce a **deep analysis** of the question, giving the next research and writing stages high-quality raw material.
+
+**Important: The direction is already set — don't re-litigate scope. Focus on depth.**
+**Important: your job is to understand the question, not answer it.**
+
+Before you start, read or review these inputs completely:
+- Current active conversation context and current user question
+- Direction call from current-session Judgment working context
+- Background already collected in current-session Background working context
+
+Identify the current user question from the active conversation context. Do not use irrelevant prior context, inferred intent, style guesses, or hidden reasoning as user input.
+
+If prior final-report content from earlier turns exists in the active conversation context or the user's current message, use it to understand historical question breakdowns, boundaries, and writing choices. This step must synthesize the current Background working context, the current Judgment working context, and the conversation context into new Analysis and Research Plan working context for this turn.
+
+Form the complete result as current-session Analysis and Research Plan working context for the next step. Do not write any intermediate file.
+
+Do not use the Write tool in this step. Keep the analysis and research plan in
+current-session working context only. In particular, do not write any
+intermediate Markdown file.
+
+Before moving to Step 4, make the research plan directly executable:
+- research subtopics
+- key gaps to verify
+- suggested search angles and keywords
+- evidence needed for each subtopic
+- short labels for each research item so Step 4 can copy them into Todo items
+
+This handoff is required. Do not move to Step 4 until the handoff is explicit
+enough to become the Step 4 Todo list without inventing a new plan. Step 4 will
+turn it into the research Todo list and execute it item by item.
+
+## What to analyze in depth
+
+Go deep on every aspect below. No drive-by bullet points.
+
+### 1. Deep sub-topic breakdown
+Within the established direction, what sub-topics does the question involve?
+**Requirement: for each sub-topic, spell out:**
+- What specifically needs researching
+- Suggested search keywords (both English and Chinese if relevant)
+- Why this sub-topic matters
+- How it connects to other sub-topics
+
+### 2. Precise concept disambiguation
+Which concepts are easy to confuse? What do the key terms actually mean in different contexts?
+**Requirement: give a precise definition and common misconceptions for each key concept. Don't just list term names.**
+
+### 3. Rough scope
+What's in scope for the research? What doesn't need to be covered?
+**Requirement:**
+- Explicitly list the dimensions that are in scope, stating what each one needs to cover
+- Explicitly list what's out of scope (or can't be covered due to insufficient information), with reasons
+- Flag borderline areas: which topics seem related but risk drifting off-core? How to decide?
+
+### 4. Question type and capabilities needed
+Which deep analytical capabilities does this question lean on most?
+**Requirement:**
+- Identify the most relevant capabilities from (not limited to): framework building, causal reasoning, non-obvious insights, critical annotation, scenario forking, comparative analysis, data-driven argumentation, historical analogy
+- Rate each identified capability's importance (high / medium / low) with reasoning
+- Give concrete usage advice: where in the answer and how each capability should be applied
+
+### 5. Key facts and verification checklist
+Which data and facts are likely central and worth cross-checking?
+**Requirement: list each fact that needs verification:**
+- Fact description
+- Why it needs verification (controversial? time-sensitive? questionable source?)
+- Likely authoritative sources
+- Timeliness considerations
+
+### 6. User profile
+From tone and word choice, infer the user's general background and what they're after.
+**Requirement:**
+- The user's likely professional background and knowledge level
+- Their probable motivation for asking this question
+- How these judgments should influence search depth and writing style
+
+### 7. Research direction and search strategy
+Concrete directions and search suggestions for the next research stage.
+**Requirement: provide a specific search strategy:**
+- Overall research direction: where to start, how to go deeper
+- Initial search terms (5–10 each in English and Chinese if relevant)
+- Priority ranking
+- Progressive search path (breadth → depth)
+- Information gaps you expect and fallback approaches
+
+### 8. Specific writing guidance
+Concrete guidance for the writing stage.
+**Requirement:**
+- Who's the likely reader? What length, depth, and style would suit them best?
+- Which insights must the final answer include? (list at least 5 specific insight-type statements)
+- What kind of concluding statements would show depth?
+- Which common shallow-answer patterns should be avoided?
+- If you could keep only one core takeaway, what should it be?
+
+## Output
+Form a thorough analysis. Remember: analyze the question, don't answer it. Every section must have substantive content — no heading-only or one-liner sections.
+
+Output language: keep the analysis in the same language as the user's query.
+
+---
+
+## Inputs
+
+- Current active conversation context and current user question
+- Direction call from current-session Judgment working context
+- Background already collected in current-session Background working context
+
+---
+
+Build a deep analysis on top of the direction call and background above. Direction is set; focus on depth.
+
+End with a clear Step 4 handoff: labeled subtopics, gaps, search angles/keywords, and evidence needs.