Visual Studio Code is a code editor that supports editing, navigating, understanding, debugging, and extending software projects. Developers use it for the edit-build-debug cycle, and the catalogue add-ons provide skills, instructions, and agents for working within the editor.
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 microsoft/vscode --skill commitgit clone --depth 1 https://github.com/microsoft/vscodeWrote 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/microsoft/vscode/commit)<a href="https://agentmods.dev/skills/microsoft/vscode/commit"><img src="https://agentmods.dev/badge/skills/microsoft/vscode/commit/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/microsoft/vscode/commit"><img src="https://agentmods.dev/badge/skills/microsoft/vscode/commit.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- Snyk pass
- NVIDIA SkillSpector warn
SkillSpector: 2 findings, up to high
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 →
- high YARA Match · line 3 YARA rule matched a hack tool or exploit indicator (offensive tools, reconnaissance, privilege escalation, or exploit frameworks).Fix: Remove offensive tool references and exploit code. Legitimate agent skills should not contain penetration testing tools, exploit frameworks, or reconnaissance utilities.
- medium Excessive Agency · line 13 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.00052 | $0.00708 |
| Opus 5.5 | $0.00021 | $0.00283 |
| Sonnet 5.5 | $0.00010 | $0.00142 |
| Haiku 4.5 | $0.00005 | $0.00071 |
Grade A, and why
commit 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 1mo 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 — 81 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Commit Changes
Help the user commit code changes with a well-crafted commit message derived from the diff, following the conventions already established in the repository.
Guidelines
- Never amend existing commits without asking.
- Never force-push or push without explicit user approval.
- Never skip pre-commit hooks (do not use
--no-verify). - Never skip signing commits (do not use
--no-gpg-sign). - Never revert, reset, or discard user changes unless the user explicitly asked for that.
- Check for obvious secrets or generated artifacts that should not be committed. If something looks risky - ask the user.
- When in doubt about staging, convention, or message content — ask the user.
Workflow
1. Discover the repository's commit convention
Run the following to sample recent commits and the user's own commits:
# Recent repo commits (for overall style)
git log --oneline -20
# User's recent commits (for personal style)
git log --oneline --author="$(git config user.name)" -10
Analyse the output to determine the commit message convention used in the repository (e.g. Conventional Commits, Gitmoji, ticket-prefixed, free-form). All generated messages must follow the detected convention.
2. Check repository status
git status --short
- If there are no changes (working tree clean, nothing staged), inform the user and stop.
- If there are staged changes, proceed with those and do not stage any unstaged changes.
- If there are only unstaged changes, stage everything (
git add -A), and proceed with those.
3. Generate the commit message
Obtain the full diff of what will be committed:
git diff --cached --stat
git diff --cached
Using the diff and the commit convention detected in step 1, draft a commit message with:
- A subject line (≤ 72 characters) that summarises the change, following the repository's convention.
- An optional body that explains why the change was made, only when the diff is non-trivial.
- Reference issue/ticket numbers when they appear in branch names or related context.
- Focus on the intent of the change, not a file-by-file inventory.
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.
- 1mo ago First seen · 81 lines · 52 tokens per session scan A 3c9118bfff59
commit is a skill published in the GitHub repository microsoft/vscode (194,191 stars, last pushed today), licensed MIT. It adds 52 tokens to every session and 708 once invoked, about $0.0002 per session on Opus 5.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
create-pr
Creates a GitHub PR with a Linear-ticket-prefixed title and a decision-led, narrative description for Prisma 8. Use when the user wants to create a pull request, open a PR, or submit changes for review.
review-implement-phase
Implements triaged review actions, commits focused fixes, and posts Done plus resolves threads. Use when the user wants only the implementation phase of the review-framework workflow.
review-triage-phase
Produces canonical review actions from fetched review state and renders action markdown. Use when the user wants only triage/action-planning for the review-framework workflow.
multiline-commit-messages
Use single-quoted strings for multiline git commit messages in the Shell tool. Prevents heredoc escaping failures that produce garbled commit messages.
safety
Check secret handling, staged changes and push targets, destructive Git operations, Docker image hygiene, and new dependencies before consequential coding actions. Use for commits, pushes, container builds or publishes, dependency additions, and explicit safety reviews.
maestro-improve
Turn filed lessons into the smallest doctrine edit. Use when a Lead assigns improvement work for one target: group pending lessons, make one evidence-linked commit per target, return it for independent challenge, and process each accepted or rejected lesson without deleting history.