Borrowing it
Nothing to install: this file belongs to snyk/snyk-ls. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/snyk/snyk-ls/main/.cursor/skills/verification/SKILL.mdgit clone --depth 1 https://github.com/snyk/snyk-lsWrote 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/snyk/snyk-ls/verification)<a href="https://agentmods.dev/skills/snyk/snyk-ls/verification"><img src="https://agentmods.dev/badge/skills/snyk/snyk-ls/verification.svg" alt="Measured on agentmods" 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.00052 | $0.02163 |
| Opus 5 | $0.00026 | $0.01081 |
| Sonnet 5 | $0.00010 | $0.00433 |
| Haiku 4.5 | $0.00005 | $0.00216 |
Grade A, and why
verification 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 — 334 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Code Verification
Verify generated code in depth before committing. This skill complements the pre-commit checklist by adding semantic analysis.
When to Use
- Before committing implementation changes
- After completing implementation steps
- When PR review feedback needs to be addressed
- When explicitly asked to verify code
- When starting a new session of an implementation plan
Verification Workflow
Copy this checklist and track progress:
Verification Progress:
- [ ] Step 1: Load project rules and standards
- [ ] Step 2: Trace code paths for modified files
- [ ] Step 3: Check for semantic changes
- [ ] Step 4: Identify code smells
- [ ] Step 5: Run security scans
- [ ] Step 6: If PR exists: trigger feedback by commenting `/review` in the PR. Wait for the bot to review. Review ALL comments in the PR feedback including the pr-review-bot comments
- [ ] Step 7: Get check results from github with gh cli. wait if necessary until the checks are complete.
- [ ] Step 8: Update implementation plan with findings
- [ ] Step 9: Fix issues (TDD REQUIRED - test first, then fix)
- [ ] Step 10: Check coverage of changed files > 80%
- [ ] Step 11: Add tests if coverage not sufficient
- [ ] Step 12: Commit changes (use commit skill for details)
- [ ] Step 13: Push changes to remote repository
- [ ] Step 14: run verification skill again
Step 1: Load Project Rules
Read and apply these project standards:
.cursor/rules/general.mdc- critical rules and workflow.github/CONTRIBUTING.md- coding standards
Key rules to verify against:
- Outside-in TDD followed
- Minimum necessary changes
- No workarounds or commented-out code
- gomock used for mocking (no custom mocks)
- Generated types used for mock responses
Step 2: Trace Code Paths
For each modified file, trace the execution flow:
- Identify entry points: API handlers, public functions, exported methods
- Follow the call chain: Map function calls through the codebase
- Verify dependencies: Check that all called functions exist and have correct signatures
- Check return paths: Ensure all code paths return appropriate values/errors
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 · 334 lines · 52 tokens per session scan A 15306554d4c9
verification is a skill published in the GitHub repository snyk/snyk-ls (83 stars, last pushed 2d ago), licensed Apache-2.0. It adds 52 tokens to every session and 2,163 once invoked, about $0.0003 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
implementing-github-advanced-security-for-code-scanning
Configure GitHub Advanced Security with CodeQL to perform automated static analysis and vulnerability detection across repositories at enterprise scale.
code-review
Perform comprehensive code review with best practices.
refactor
Suggest refactoring improvements for code quality.
plugin-code-review-orchestrated
Orchestrates a code review of the spring-plugin repository through scope/context passes, routing, domain reviewer subskills, and per-artifact validation. Use when asked to review a PR, diff, commit, branch, module, or file set, to run a full orchestrated review, or to produce a validated review report.
review-async-lifecycle
Normative reviewer for EDT safety, coroutines, cancellation, read/write actions, disposal, listeners and async lifecycle in the explyt spring-plugin. Use during orchestrated code review when the diff touches threading, background tasks, read or write actions, listeners, MessageBus, Disposable ownership or progress…
review-core-correctness
Normative mandatory reviewer for correctness, contracts, architecture sanity, UX behavior, code quality and tests in the explyt spring-plugin codebase. Use during orchestrated code review of a PR, diff, commit or branch, or when asked to review correctness, logic, architecture or test coverage of plugin changes.