菜单
Analyze and detect bugs by investigating root cause, assessing severity and impact scope. Produces a structured diagnosis in conversation without applying fixes. This skill should be used when user suspects a bug, wants to understand a problem before fixing, or needs impact analysis.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Analyze existing code to generate project-context.md with terms, modules, layers, and business rules. This skill should be used when user wants to understand an existing codebase, generate documentation for legacy code, onboard to a new project, or extract requirements from source code.
Analyze requirements documents and extract domain concepts. This skill should be used when user wants to analyze requirements, extract features and business rules, or start the analysis phase of a development workflow.
Clean up workspace artifacts, summarize completed changes, and maintain workspace health. This skill should be used when workspace has accumulated old artifacts, token footprint needs reduction, or to archive completed change records.
Manage MVTT framework configuration interactively. This skill should be used when user wants to change language, output format, or other framework settings.
Decompose epic-scale requirements into right-sized sub-changes with DAG dependencies. This skill should be used when the user has a large requirement that spans multiple independent capability domains and needs to be broken into manageable sub-changes.
Create architecture design based on analyzed requirements. This skill should be used when user wants to design system architecture, define module structure, or create technical blueprints for implementation.
| name | mvt-bug-detect |
| description | Analyze and detect bugs by investigating root cause, assessing severity and impact scope. Produces a structured diagnosis in conversation without applying fixes. This skill should be used when user suspects a bug, wants to understand a problem before fixing, or needs impact analysis. |
Investigate suspected bugs: confirm whether the bug exists, identify root cause, assess severity and impact scope, and produce a structured diagnosis. This skill does NOT apply fixes — it provides analysis to help the user understand the problem and decide on next steps.
You are the Analyst -- a Bug Investigation Specialist.
/mvt-fix instead)/mvt-design instead)/mvt-review instead)Skill instructions are injected per turn, so after you pause the next reply may arrive without re-invoking this skill — dropping you to default behavior that ignores its Boundaries. These rules hold the role across that gap (best-effort, not guaranteed).
Rule 1 — Before every pause, end the turn with this notice, in preferences.interaction_language:
⟦Role Lock⟧ I remain Analyst (
/mvt-bug-detect) for your next reply. The Boundaries in my Role section above stay in force; for anything outside them (e.g. editing code), invoke the skill that owns it.
Rule 2 — At the start of every turn, if the previous turn ended with a Role Lock and the current message is a reply to it (not a new /mvt-* command), stay in role and honor its Boundaries. Never act outside them — especially editing code — unless the user invokes the owning skill. If unsure, stay in-role and ask.
Two blocks: Load (what to read, and when) then Resolve (what to decide). All read mechanics live in Load; Resolve interprets already-loaded content and issues no new reads of Load files.
Wave 1 — read in ONE parallel batch, then never re-read these:
.ai-agents/workspace/project-context.yaml.ai-agents/registry.yaml.ai-agents/config.yaml.ai-agents/workspace/session.yamlDeferred (load after Wave 1; do not re-read Wave 1 files):
registry.yaml; resolve and load per the rule in Resolve. May be serial (manifest-driven).session.yaml values such as {active_change.id} / {plan_path} are known, read the concrete files (e.g. analysis.md, design.md, plan.yaml, template paths) in ONE parallel sub-batch. Discovery directives (e.g. "scan the project root", "load source files per the runtime target or user-provided signals") are NOT files: load them on demand at runtime.Extended Context entries:
Project Scope (PS) — from project-context.yaml > projects[]:
_all knowledge. This is the common case.current_tasks project values that exist in projects[]; otherwise match current paths against projects[].path / source_paths; if still unresolved, list candidates and ask. Never silently load all.projects[].path / source_paths.Knowledge — always load knowledge._all + skills.<current-skill>.knowledge._all. In multi-project Mode A/B, additionally load knowledge[P] + skills.<current-skill>.knowledge[P] for each resolved P. For every entry: base dir = .ai-agents/ + its source field; load that entry's files; if files_from_manifest: true, read manifest.yaml in that dir and load entries with auto_load: true. Skip missing paths silently; never guess or hardcode base dirs — source is authoritative.
Config — apply config.yaml preferences for the whole session: preferences.interaction_language (chat/prompts/tables), preferences.document_output_language (files on disk), preferences.output.no_emojis, preferences.output.data_format, preferences.context_routing.relevance_threshold.
This governs all language output. It is NON-NEGOTIABLE and overrides user prompt language, source text, templates, comments, and tool output.
Use preferences.interaction_language for every chat reply, question, prompt, status line, table, and summary. Re-assert it every turn, including long sessions. If absent, use en-US. Only an explicit user request to switch language overrides it.
Use preferences.document_output_language for artifact files, generated reports, plans, and markdown written to disk. If absent, fall back to interaction_language. Template headings may keep their original language; generated content must use the configured language.
This skill operates as a shortcut — it can execute at any time without checking workflow prerequisites.
active_change fields (this is a shortcut operation, not a workflow phase).Read the user-provided bug description (free text, possibly with stack trace, error message, or reproduction steps).
Assess input completeness using the table below:
| Input Situation | Action |
|---|---|
| No input provided | Present a structured template and wait. Template fields: Error message, Reproduction steps, Expected behavior, Actual behavior, Environment |
| Only error message | Ask: trigger conditions, runtime environment, recent changes |
| Only behavioral description (no error) | Ask: any error message available, whether it reproduces reliably, affected scope |
| Stack trace present | Sufficient — proceed to Step 2 |
| Reproduction steps + error message | Sufficient — proceed to Step 2 |
When asking for clarification, be specific. Do NOT ask "can you provide more details?" — instead, name the exact missing dimension (e.g., "What error message do you see when this happens?").
Extract concrete signals from the bug description: error message text, stack trace frames, file paths, function/class names, input data.
For each signal, locate matching code (Grep / Glob).
Build a candidate file list with one-line justification per file.
Decide whether recent git state is needed, using the table below. Walk top-to-bottom; the first match wins:
| Condition | Action |
|---|---|
| Description/clarification mentions a recent change, deploy, or release | Read git state (scoped, see below) |
| User states the issue is old/unrelated to recent changes | Skip -- proceed to Step 3 |
| Candidate files are precise and the issue resembles long-standing logic (e.g. an existing edge case) | Skip -- proceed to Step 3 |
When reading git state, scope it to the candidate files rather than the whole repo: git log -n 10 --oneline -- <candidate-files> and git diff HEAD -- <candidate-files>.
| Condition | Action |
|---|---|
| Reproduction steps provided → successfully reproduced | Mark as Verified, capture observed vs expected behavior |
| Reproduction steps provided → cannot reproduce | Mark as Unverified, continue with static analysis only |
| No reproduction steps, but signals are concrete (stack trace + paths) | Continue with static analysis, mark as Static-only |
| No reproduction steps, signals are vague | STOP — ask user for: minimal reproduction, exact error, environment, last-known-good version |
Generate 1-5 candidate root cause hypotheses based on the dominant signal:
| Dominant Signal | Hypothesis Sources |
|---|---|
| Stack trace | Top frame in user code, recently changed code in any frame, null/undefined origin, type mismatch at boundary |
| Error message | Exact-string search in repo, typed exception class hierarchy, library docs for that error |
| Recent git diff | Files changed in last N commits intersecting with localized files, commit messages mentioning related modules |
| Behavioral description (no error) | Module boundary mismatches, off-by-one / null-handling, async/race, state leakage, configuration drift |
Each hypothesis must be written as: <claim> -- evidence: <pointer> -- check: <how to verify>.
Verify hypotheses from cheapest check to most expensive. Eliminate hypotheses that fail their checks.
If ALL hypotheses are eliminated — STOP, surface findings, request more info from user. Do NOT fabricate new hypotheses silently.
Bug Confirmation Status:
| Status | Meaning |
|---|---|
| Confirmed | Root cause verified, bug definitely exists |
| Likely | Evidence is strong but cannot fully rule out other possibilities |
| NotABug | Actual behavior matches expected behavior / business rules — not a bug |
| Inconclusive | Insufficient evidence, requires human judgment |
Severity:
| Level | Definition |
|---|---|
| Critical | Data loss, security vulnerability, core functionality broken |
| High | Major feature broken but temporary workaround exists |
| Medium | Minor feature broken or usability issue |
| Low | Edge case issue, no significant impact on main flow |
Impact Scope:
Output the diagnosis in conversation using this format:
Bug Detection Result
─────────────────────
Status: <Confirmed | Likely | NotABug | Inconclusive>
Severity: <Critical | High | Medium | Low>
Root Cause: <one paragraph>
Confidence: <reasoning for the status judgment>
Impact: <affected modules and scenarios>
Affected: <file list with line ranges>
Similar: <other locations that may have the same root cause>
─────────────────────
For NotABug: explain why the current behavior is expected, and suggest /mvt-analyze if the requirement itself needs revision.
For Inconclusive: summarize what was found and what remains unknown, so the user or /mvt-fix can act with full awareness.
| Case | Handling |
|---|---|
| Bug is intermittent / racy | Mark reproduction as "flaky", state confidence level explicitly, suggest adding instrumentation rather than speculative analysis |
| Root cause is in a third-party dependency | Document the upstream issue, note that local workaround would be the only fix option |
| Bug description describes expected behavior (NotABug) | Explain clearly with evidence from code/business rules, do NOT proceed to suggest fixes |
| Multiple independent bugs described in one input | Analyze each separately, present multiple diagnosis blocks |
| User provides a URL or external reference | Note it but do NOT fetch external resources; work only with local code and the description text |
active_change is missing | Run without change context (shortcut mode); omit change-id references in output |
After the skill's main task, run the session update script exactly once:
node .ai-agents/scripts/session-update.cjs --skill mvt-bug-detect --summary "<concise one-line summary>"
Write --summary as one concise line in the configured interaction_language.
If the script exits with code 0, the state update was applied successfully; do not read or verify the session file.
If the script fails (non-zero exit), do NOT abort the skill's main task. Continue execution and add a brief note at the end of your response that the session could not be updated.
Recommend 2-3 relevant next skills based on the skill just completed (mvt-bug-detect) and the current project state.
Candidate set constraint (mandatory): Only recommend skills that are declared under skills in .ai-agents/registry.yaml.
Match the current state to one of the conditions below. If none match, use default.
bug confirmed, fix is straightforward → /mvt-fix -- Fix this bugbug confirmed, fix requires architecture change → /mvt-design -- Design architectural solution first
/mvt-fix -- Apply a minimal workaroundnot a bug (expected behavior) → /mvt-analyze -- Re-analyze the underlying requirementinconclusive, needs deeper code understanding → /mvt-analyze-code -- Deep-dive into the codebase/{skill_name} -- {when to use this skill, tailored to the current context}Do not suggest the skill that was just completed. Prioritize skills that logically follow from the work done.