/vscode-doctor

name: vscode-doctor
description: Diagnose slow or freezing VS Code-compatible editors with evidence-first, zero-hardcoded-assumption workflow. Use when the user reports editor lag, typing delay, UI freezes, extension host stalls, file watcher noise, high editor CPU/RSS, uses VS Code/Cursor as a file browser over a large folder, or wants a safe editor performance audit.
allowed-tools: Bash, Read
metadata:
  argument-hint: "[workspace-root optional]"

VS Code Doctor

Diagnose editor performance from the current machine state. Do not import old observations, fixed paths, fixed extension names, fixed OS bugs, or fixed generated-directory lists into the diagnosis.

Non-Negotiables

• No hardcoded local paths. Use the user's stated workspace, discovered editor status, or explicit placeholders.
• No fixed root cause order. Rank only by fresh evidence from this run.
• No fixed extension blocklist. Treat extension names as evidence only when they appear in live output or user-provided screenshots.
• No fixed generated-directory list. Discover ignored/generated paths from the workspace, editor settings, repository metadata, or user-provided patterns.
• No fixed benefit percentages. If there is no before/after baseline, say the impact cannot be reliably quantified.
• Do not treat whole-machine load as the editor diagnosis. Record it as context, but keep conclusions and actions focused on editor evidence.
• Treat collector output as sensitive. It can expose local paths, project names, process command lines, workspace names, log paths, and extension identifiers. Redact sensitive details before sharing externally.
• No write operations by default. Do not edit settings, disable extensions, delete caches, run system defaults, change environment variables, or kill processes without explicit confirmation.

Default Simple Mode

Default to a non-technical user experience unless the user asks for details.

• Treat this skill as invisible to the user: they cannot see the collector, logs, or settings changes unless you explain them.
• Start with one plain-language sentence: `现在看起来是：<正常 / 忙 / 可疑 / 还不确定>` and immediately say what you checked or will check.
• Ask at most one question before collecting evidence. Prefer discovering the editor/workspace automatically.
• Avoid leading with terms like RSS, extension host, FSEvents, renderer, or language server. Put those under `Technical details`.
• Translate technical causes into user-facing labels:
• file watcher or rescans -> "background file scanning"
• extension host -> "plugin background process"
• renderer/UI process -> "editor window rendering"
• language server or linter -> "code intelligence"
• workspace surface -> "the folder range the editor is watching"
• Never present a long table as the main answer for a non-technical user.
• Do not use process names such as `systemstatusd`, `WindowServer`, or `coreaudiod` as the headline. Translate them first, for example: "主要压力来自系统后台/窗口渲染/音频服务，不是编辑器本体".
• Present two or three choices as actions, each with:
• what it changes
• whether it is reversible
• what the user might notice
• how to verify it helped
• Keep "do nothing and observe" as a valid option when evidence is weak.
• If you ran commands or changed files, the final answer must begin with a plain-language action log, not only a diagnosis.
• Never claim the optimization helped unless there is a fresh after-snapshot or user-visible verification. If there is no clean before/after, say the expected effect is a hypothesis and give the next verification step.

Diagnosis-only report shape:

现在看起来是：...

我检查了：...

建议先做：...

可选操作：
1. 只观察，不改设置
   适合：...
   会影响：不会
   验证：...
2. 轻量降噪，只处理明显的生成/缓存目录
   适合：...
   会影响：这些目录仍能打开编辑，但外部变化可能需要手动刷新
   撤回：删掉这几条 workspace 设置
3. 深度排查插件
   适合：...
   会影响：先不禁用插件，只做 profiling / bisect 建议

Technical details:
- ...

After-action report shape:

我刚刚做了：
- 看了什么：...
- 改了哪里：...
- 为什么改：...

你可能会感受到：
- ...

不会发生什么：
- ...

副作用：
- ...

怎么确认有效：
- ...

怎么撤回：
- ...

Technical details:
- ...

Rules for after-action reports:

• "看了什么" should name evidence in user terms, such as "editor logs", "current CPU list", "workspace settings", or "large generated folders".
• "改了哪里" must include exact file paths when files were edited.
• "为什么改" must connect each change to observed evidence, not generic optimization folklore.
• "你可能会感受到" must be phrased as possible outcomes, not guaranteed improvement.
• "不会发生什么" must call out important non-effects, for example "files are not deleted" or "folders are not hidden" when true.
• "副作用" must include search/watch/editing tradeoffs for settings changes.
• "怎么确认有效" must include a concrete user action or command and a time window when observation is needed.
• "怎么撤回" must include a backup path or exact rollback command when a file was changed.

Risk Boundaries

Make these risks explicit before changing settings, disabling extensions, deleting caches, changing system/editor launch flags, or preparing public posts:

• **Privacy leakage**: collector output can expose local paths, private project names, process command lines, workspace names, log paths, extension identifiers, remote host names, or container paths. Share redacted summaries, not raw collector output.
• **Misdiagnosis**: short after-snapshots are immediate checks, not proof of long-term improvement. Do not claim the skill fixed all editor lag or unrelated system load.
• **Workspace setting side effects**: `files.exclude`, `search.exclude`, watcher excludes, and language-tool excludes can hide files, reduce search coverage, or suppress diagnostics. Prefer workspace-scoped settings, show the diff first, and include rollback.
• **Extension side effects**: disabling an extension can remove formatting, linting, IntelliSense, auth helpers, or remote tooling. Prefer profiling, Extension Bisect, or workspace-scoped disablement of extensions named by evidence.
• **Cache/log cleanup side effects**: deleting cach