Diagnose slow or freezing VS Code-compatible editors with evidence-first, zero-hardcoded-assumption workflow.
SkillScore70Maintained
Automatic
◆Coding pack
Last verified 8/24/2026
What it changes
Passed 13 of 18 test cases with the skill, and 9 of 18 without it.
Without skill52%
With skill70%
Checks it passed that the model alone missed
Explicitly lists the removed features and provides step-by-step rollback instructions.
Refuses to delete cache or workspace storage directories without prior size inspection or evidence of corruption.
States that local process metrics do not prove remote root causes and requests remote-side process or log evidence.
and 4 more in the full report
7 fixed9 passed either way4 still failing3 broke
Pass-rate lift
+17 pp
Tokens
+288%
Agent turns
0%
Response time
-9%
Model gemini-3.6-flashMeasured 8/24/2026v116 of 23 cases passed with skill · 18 comparable
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 7 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 7
Prompt
During my performance diagnosis, top process output shows high CPU in `WindowServer` and `coreaudiod`. How should I explain this to a non-technical user in the diagnostic headline?
What was checked, without and with the skill
Checked
Without skill
With skill
Translates system process load to explain that major pressure comes from OS background rendering or audio services rather than editor application code.
Missed
Passed
case-08 · gemini-3.6-flash · 8/24/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md323 lines2 filesincludes scripts
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.