菜单
Full three-layer verification after any change — LSP diagnostics + compiler build + test suite, ranked by severity. Use after completing any edit, refactor, or feature to confirm nothing is broken before committing.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/TuYv/ccpm --skill lsp-verify命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
基于 SOC 职业分类
正在显示 SKILL.md
| name | lsp-verify |
| description | Full three-layer verification after any change — LSP diagnostics + compiler build + test suite, ranked by severity. Use after completing any edit, refactor, or feature to confirm nothing is broken before committing. |
| user-invocable | true |
| allowed-tools | mcp__lsp__get_diagnostics mcp__lsp__run_build mcp__lsp__run_tests mcp__lsp__get_tests_for_file mcp__lsp__suggest_fixes mcp__lsp__format_document mcp__lsp__apply_edit |
| license | MIT |
| compatibility | Requires the agent-lsp MCP server (github.com/blackwell-systems/agent-lsp) |
| metadata | {"optional-capabilities":"codeActionProvider documentFormattingProvider","tool_permissions":{"phases":{"test_correlation":"[Truncated]","diagnostics":"[Truncated]","build":"[Truncated]","tests":"[Truncated]","fix_and_format":"[Truncated]"},"global_forbidden":["mcp__lsp__simulate_*","mcp__lsp__rename_symbol"]}} |
Requires the agent-lsp MCP server.
Run this skill after any significant change to verify correctness at every level:
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 diagnosticschanged_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.
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.
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.
mcp__lsp__run_tests({ "workspace_dir": "<workspace_dir>" })
Does NOT require start_lsp. Returns .
{ "passed": bool, "failures": [...] }Large output warning: run_tests on large repos can return hundreds of
thousands of characters and exceed the context window. If the result is saved
to a file rather than returned inline, do NOT attempt to read the whole file.
Instead, search it for failures:
grep -E "^(FAIL|--- FAIL)" <output_file>
Or scope tests to the correlated test files from the pre-step to avoid the size issue entirely:
GOWORK=off go test -count=1 -short ./internal/mypackage/... 2>&1 | grep -E "FAIL|ok"
Using test correlation: If the pre-step produced a source → test file map, cross-reference failing test names against that map. For each failure, note whether it is in a correlated test file (directly covers the changed code) or an unrelated test file (collateral failure from a shared dependency). This distinction guides where to investigate first.
Test failures are blocking — they indicate regressions or unmet contracts.
After running all three layers, produce a structured report:
## Verification Report
### Layer 1: LSP Diagnostics
[CLEAN / N errors, M warnings]
<details if N > 0 or M > 0>
Errors:
- file:line - message
Warnings:
- file:line - message
</details>
### Layer 2: Build
[PASSED / FAILED - N errors]
<details if FAILED>
- error message (file:line)
</details>
### Layer 3: Tests
[PASSED / FAILED - N failures]
<details if FAILED>
- test name: message (file:line) [correlated / unrelated]
</details>
<if test correlation map exists>
Test files covering changed source:
changed/source/file.go → test/source_file_test.go
</if>
### Summary
Overall: CLEAN / NEEDS ATTENTION
Blocking issues: [errors that must be fixed before shipping]
| Layer | Errors | Warnings |
|---|---|---|
| LSP Diagnostics | Blocking | Advisory |
| Build | All blocking | N/A |
| Tests | All blocking | N/A |
Build errors and test failures block shipping. LSP warnings and style suggestions are advisory — document them but do not treat as blockers unless they indicate logical errors.
If all three layers are CLEAN and changed_files is known, offer to format
the changed files before committing:
mcp__lsp__format_document({ "file_path": "<changed-file>" })
Apply the returned TextEdit[] via apply_edit if non-empty. Run once per
changed file. Skip if the user did not request formatting.
If Layer 1 returns errors, the LSP may offer quick fixes. For each error
location, call suggest_fixes to surface available fixes:
mcp__lsp__suggest_fixes({
"file_path": "<file>",
"line": <error line>,
"column": <error column>
})
Returns a list of available actions (e.g. "Add missing import", "Implement interface methods", "Remove unused variable"). Pick the most appropriate one and apply it:
mcp__lsp__apply_edit({
"file_path": "<file>",
"old_text": "<text to replace>",
"new_text": "<replacement>"
})
Or if the code action returns a workspace_edit, pass it directly to
apply_edit via the workspace_edit parameter.
After applying, re-run Layer 1 on the affected file to confirm the error is resolved before moving on. Do not apply multiple code actions in bulk without verifying each one — they may interact.
When to use: Compile errors from missing imports, unimplemented interface methods, or type mismatches often have one-click fixes available. Manual reasoning is still required for logic errors.