Getting it into your agent
There is no command for this one: it runs only inside a plugin, and the catalogue could not identify which plugin ships it. The source is linked below.
Wrote 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/blackwell-systems/agent-lsp/lsp-verify)<a href="https://agentmods.dev/skills/blackwell-systems/agent-lsp/lsp-verify"><img src="https://agentmods.dev/badge/skills/blackwell-systems/agent-lsp/lsp-verify/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/blackwell-systems/agent-lsp/lsp-verify"><img src="https://agentmods.dev/badge/skills/blackwell-systems/agent-lsp/lsp-verify.svg" alt="Reviewed on agentmods" width="80" height="20"></a>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.00046 | $0.02024 |
| Opus 5 | $0.00023 | $0.01012 |
| Sonnet 5 | $0.00009 | $0.00405 |
| Haiku 4.5 | $0.00005 | $0.00202 |
Grade A, and why
lsp-verify 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 9d 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 — 261 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Requires the agent-lsp MCP server.
lsp-verify: Three-Layer Verification
When to Use
Run this skill after any significant change to verify correctness at every level:
- After editing source files (logic changes, refactors, new functions)
- After merging or rebasing branches
- After dependency updates or configuration changes
- Before committing or pushing code
Input
workspace_dir(required): absolute path to the workspace root (e.g./Users/you/code/myproject)changed_files(optional): list of files you edited — used for targeted diagnostics
Execution
Pre-step: Test correlation (when changed_files is provided)
Before running the three layers, call get_tests_for_file for each changed
source file to build a source → test file map:
mcp__lsp__get_tests_for_file({ "file_path": "<changed/source/file>" })
Returns the test files that correspond to each source file. Store this map —
it is used in Layer 3 to focus failure analysis. If changed_files is unknown,
skip this step.
Run all three layers in parallel — they are independent and do not need to be sequenced. Issue all three calls in the same message to minimize wall time.
Layer 1: LSP Diagnostics
Call mcp__lsp__get_diagnostics with file_path set to each changed file.
get_diagnostics takes a file path, not a workspace directory.
Note: requires LSP to be initialized. If not yet running, call start_lsp
with the workspace root first.
mcp__lsp__get_diagnostics({ "file_path": "<path/to/changed/file>" })
Call once per changed file. If you don't know which files changed, call it on the primary files touched in this session. Rank results by severity: errors first, then warnings.
Layer 2: Build
mcp__lsp__run_build({ "workspace_dir": "<workspace_dir>" })
Returns { "success": bool, "errors": [...] }. A failed build means the code
does not compile. Build errors are blocking — must be resolved before shipping.
Layer 3: Tests
mcp__lsp__run_tests({ "workspace_dir": "<workspace_dir>" })
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.
- 9d ago First seen · 261 lines · 46 tokens per session scan A 3443b99104f2
lsp-verify is a skill published in the GitHub repository blackwell-systems/agent-lsp (123 stars, last pushed today), licensed MIT. It adds 46 tokens to every session and 2,024 once invoked, about $0.0002 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-08-30.
Other skills, from other repositories
analyze-usage
Use when asked to analyze codescout tool usage, check for error patterns, audit tool health, generate a usage report, spot anti-patterns, or clear usage statistics to start fresh.
mastermind-test-audit
Read-only review of whether the tests in a finished change actually prove its behaviour — changed code no test reaches, a test exercising a different path than the one that changed, an assertion edited to match the new output, and a suite that ran nothing. Use after implementation, and whenever a change claims to be…
mastermind-browser-verification
Turn "I opened it and it looks fine" into recorded evidence — accessibility tree over screenshot, console and network errors as mechanical failures, viewport and colour-scheme checks as a checklist, and anything unchecked marked unchecked. Use after implementing a UI change in a client that can drive a browser.
codemeridian-test-planning
Plan focused tests with CodeMeridian by finding relevant test shields, coverage gaps, impacted behavior, and the smallest useful test set before implementation.
mastermind-test-impact
Build a focused, evidence-backed test plan from mastermind impact or mmcgtestimpact. Use when deciding which tests to run for a change, explaining direct/transitive/heuristic candidates, or sequencing fast feedback before the repository's required full test gate.
Go Patterns
Use this skill when building Go services/CLIs and you want practical patterns for package layout, error handling, concurrency, and testing that keep code readable and reliable.