Vscode Doctor

Analysis

Classify each finding by evidence strength:

• High priority: current CPU/RSS/log/status evidence directly explains the symptom and the next experiment is low risk.
• Medium priority: plausible contributor with partial evidence, or a safe optimization whose current impact is not proven.
• Low priority: maintenance or cleanup item without direct evidence of causing the symptom.

Common evidence types to look for, without assuming any one must exist:

• editor main/renderer/extension-host process CPU or RSS
• language service or extension child-process CPU/RSS
• file watcher errors or repeated workspace rescans
• large workspace surface area from editor status, VCS metadata, or ignored/generated paths
• repeated extension-host unresponsive signals
• UI process pressure that correlates with editor renderer activity
• cache or storage size only when it is large enough to plausibly matter
• remote/container/network-filesystem markers when the workspace is not purely local

When the user wants a file-browser-like workspace:

• Treat the goal as "keep files visible and editable while reducing background work."
• Prefer narrowing the active workspace to the current repo when editing deeply.
• If the broad workspace must stay open, recommend targeted workspace-level exclusions for noisy generated or dependency paths.
• Do not assume that hiding files is acceptable; ask or present it as a separate option.

When recommending extension changes:

• Use only extension names seen in live output, user screenshots, or logs.
• Prefer workspace-scoped disablement or profiling over global disablement.
• If the evidence only shows “extension host high,” recommend profiling or bisecting before naming a culprit.

When recommending workspace exclusions:

• Prefer exclusions derived from the project's own ignored/generated paths.
• If you propose a generic pattern, label it as a template for user review, not as evidence.
• Prefer workspace settings over global settings when the issue is tied to one workspace.
• For a preserved large workspace, prefer workspace-scoped settings such as files.watcherExclude, search.exclude, and supported language-tool excludes. Use files.exclude only when the user wants paths hidden from Explorer.
• Keep recommendation and execution separate: first show the proposed setting diff, evidence, expected effect, verification command, and rollback. Apply it only after explicit user confirmation.
• Distinguish the VS Code settings clearly:
  • files.watcherExclude: stops continuous file-change watching for matching paths; files can still be opened, edited, and saved, but external changes may need manual refresh or reopen.
  • search.exclude: removes matching paths from default global search; files remain visible and editable, and users can temporarily search them by disabling exclude/ignore settings in the search UI.
  • files.exclude: hides matching paths from Explorer; avoid this for file-browser mode unless the user explicitly wants the directory hidden.
• For "visible but less noisy" workflows, prefer files.watcherExclude plus search.exclude, not files.exclude.
• Verify watcher changes with fresh watcher logs, editor process CPU/RSS, and user-visible responsiveness; do not expect code --status file counts to prove the benefit by itself.

When recommending language, lint, Git, or AI-assistant settings:

• Treat settings such as python.languageServer, ruff.*, git.autorefresh, git.autoRepositoryDetection, and github.copilot.* as optional load-reduction experiments, not default fixes.
• State the feature cost before recommending them. For example: disabling a language server reduces diagnostics/completion; disabling Git auto-detection reduces Source Control discovery; disabling Copilot removes AI assistance in that workspace.
• Prefer profile-scoped or workspace-scoped experiments over global user settings.
• If the user says they only care about watcher/search pressure, do not propose these settings.

File Browser Option Ladder

Use this when the user treats VS Code or Cursor primarily as a file browser over a large folder. Present options explicitly before any write:

1. Conservative browsing: keep coding features on; add only evidence-backed files.watcherExclude and search.exclude for high-churn/generated paths. This is the default when the user still edits code and wants IntelliSense, linting, Git refresh, or AI assistance.
2. Large-folder quiet mode: keep files visible and editable, but reduce background analysis with workspace-scoped language-tool excludes or Git auto-detection/auto-refresh reductions when those tools are installed or already active. Validate exact setting names from installed extension schemas or current settings before proposing JSON.
3. File-browser profile: for users who explicitly say they only browse/edit files and do not need coding intelligence, offer a separate VS Code/Cursor profile or workspace-scoped proposal that disables or quiets language servers, linting, AI code search, dependency scanners, test discovery, minimap, and motion-heavy UI. Name the lost features plainly.

Do not require live evidence of high CPU from Ruff, Copilot, Dependi, Python, Rust, or Git before offering option 3 when the user's intent is explicitly a lightweight file-browser experience. Still do not apply it automatically. Show the proposed diff, say what capability is removed, and include rollback.

Large Workspace Playbook

Use this when the user wants to keep a parent directory open.

1. Confirm the active editor still reports the large workspace in --status.
2. Identify noisy paths only from fresh evidence:
   • file watcher log paths and timestamps
   • current search/index processes such as ripgrep
   • ignored/generated directories found in the workspace
   • language service child processes and installed extension schemas
3. Propose the smallest workspace-scoped change:
   • files.watcherExclude for paths causing watcher drops or generated directories
   • search.exclude for generated/cache directories that pollute search
   • files.exclude only for paths the user should not browse in Explorer
   • language-tool excludes only when the running tool and schema support them
4. Do not disable extensions or clear caches unless current evidence points there and the user confirms the specific experiment.
5. Verify without changing the goal: after the change, confirm the large workspace is still open and compare watcher/search/language-service evidence.

Avoid saying the workspace file count should drop after watcher/search excludes. code --status may still report the same workspace surface; the expected improvement is fewer watcher storms, less noisy search/index work, or quieter language-service processes.

Advanced Probe Playbooks

Use these modules when baseline evidence or user wording points beyond simple watcher/search cleanup.

When a probe points to an editor/Electron, OS, extension, or remote upstream issue, report it as a diagnosis with a workaround or next experiment. Do not claim the skill can directly fix upstream bugs.

Report Template

Use the simple report shape by default. Use this technical structure only when the user asks for a detailed report or the situation is complex:

## Editor Performance Diagnosis

### Evidence
| Signal | Current value | Source | Confidence |
|----|----|----|----|
| ... | ... | ... | high/medium/low |

### Priority
#### High
1. ...

#### Medium
1. ...

#### Low
1. ...

### Options
| Option | When to use | Expected impact | Cost | Verify | Roll back |
|----|----|----|----|----|----|
| ... | ... | Cannot quantify without baseline / based on observed delta | ... | ... | ... |

### Next Step
Ask the user which option to run first. Do not apply changes until they confirm.

If the user wants a social-media record, add a compact section:

### Shareable Summary
- Goal: ...
- Baseline evidence: ...
- One change: ...
- After evidence: ...
- Caveat: ...
- Redaction: local paths/project names/process command lines reviewed before sharing.

Only include measured deltas. If the after window is short, say it is an immediate check rather than proof of long-term improvement.

Verification

Before claiming improvement, collect a fresh after-snapshot with the same collector inputs used for the baseline. Compare only observed values:

## Before / After

| Metric | Before | After | Result |
|----|----:|----:|----|
| ... | ... | ... | improved / unchanged / worse / unknown |

Conclusion:
- Experiment result: ...
- Remaining evidence: ...
- Next step: ...
- Rollback: ...

If the before snapshot is missing, write: 缺少调整前 baseline，无法可靠量化收益.

Regression prompts and expected behaviors are documented in evals/README.md and evals/evals.json; use them when changing the collector or diagnosis workflow.