Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add majiayu000/spellbook --skill vscode-doctorgit clone --depth 1 https://github.com/majiayu000/spellbookWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/majiayu000/spellbook/vscode-doctor)<a href="https://agentmods.dev/skills/majiayu000/spellbook/vscode-doctor"><img src="https://agentmods.dev/badge/skills/majiayu000/spellbook/vscode-doctor/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/majiayu000/spellbook/vscode-doctor"><img src="https://agentmods.dev/badge/skills/majiayu000/spellbook/vscode-doctor.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector warn
SkillSpector: 1 finding, up to medium
These are SkillSpector’s own severities. On a checked sample its high-severity flags on skills were ~96% false positives — a documented command, a public API, a “never do X” rule — so we show them as a caution to read, not a verdict. Why →
- medium Excessive Agency · line 141 Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.Fix: Add human-in-the-loop confirmation for destructive, irreversible, or high-impact operations. Never auto-execute commands that modify files, send data, or alter system state.
What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00075 | $0.04511 |
| Opus 5 | $0.00037 | $0.02256 |
| Sonnet 5 | $0.00015 | $0.00902 |
| Haiku 4.5 | $0.00007 | $0.00451 |
Grade A, and why
vscode-doctor scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 7d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 332 lines — stays where its author put it; the contents beside it link to each section on GitHub.
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, orcoreaudiodas 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.
What ships with it
3 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 7d ago First seen · 332 lines · 75 tokens per session scan A 715750a18d1f
vscode-doctor is a skill published in the GitHub repository majiayu000/spellbook (278 stars, last pushed today), licensed MIT. It adds 75 tokens to every session and 4,511 once invoked, about $0.0004 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-03.
Other skills, from other repositories
workflow
A workflow skill for embedded-device projects that plans and runs building, flashing, debugging, observing, and diagnosis tasks.
pneuma-session
Instructions for renaming an active Pneuma session and replacing its default preview with a useful title and summary. A Pneuma session is one work area inside a larger project.
cheese
Route an idea, path, pull request, issue, failure, question, or bare /cheese to the correct workflow skill. Use this skill for /cheese, routing requests, help requests, or opening messages without a named workflow skill.
joycraft-bugfix
Structured bug fix workflow — triage, diagnose, discuss with user, write a focused spec, hand off for implementation.
x-bug2rag
A knowledge-capture tool that turns reusable bug explanations into a local RAG collection, meaning a searchable store of text that an agent can retrieve later. It records the trigger, incorrect implementation, correct implementation, and observable difference.
x-cr
A software-correctness investigation skill for finding why code behaves differently from what was expected. It uses evidence from code paths, specifications, tests, logs, and changes to assess possible causes.