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/implementation/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/implementation)<a href="https://agentmods.dev/skills/snyk/snyk-ls/implementation"><img src="https://agentmods.dev/badge/skills/snyk/snyk-ls/implementation/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/snyk/snyk-ls/implementation"><img src="https://agentmods.dev/badge/skills/snyk/snyk-ls/implementation.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
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.00062 | $0.01270 |
| Opus 5.5 | $0.00025 | $0.00508 |
| Sonnet 5.5 | $0.00012 | $0.00254 |
| Haiku 4.5 | $0.00006 | $0.00127 |
Grade A, and why
implementation 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 — 242 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Start Implementation Task
Workflow Overview
Check Plan → [Create if missing] → TEST FIRST → Implement → Test & Lint → Commit → Session Hand-off
TDD is NON-NEGOTIABLE: Every code change requires a failing test BEFORE implementation.
Phase 1: Initialize
1.1 Get Issue Context
# Extract issue ID from branch
git branch --show-current
The issueID follows format XXX-XXXX (e.g., IDE-1718).
1.2 Check for Implementation Plan
Look for: ${issueID}_implementation_plan/${issueID}_implementation_plan.md
If plan exists: Read it, note current progress, continue from last checkpoint.
If no plan: use skill create-implementation-plan to create one
Phase 1: Planning
Analysis
- Files to modify: [list files]
- Files to create: [list files]
- Packages affected: [list packages]
Flow Diagrams
See: docs/diagrams/${issueID}_*.png
Phase 2: Implementation (TDD)
** read and use testing skill for TDD instructions **
Steps
- Step 1: [description]
- Step 2: [description]
- Step 3: [description]
Phase 3: Review
- All tests pass (
make test) - Smoke tests pass (
SMOKE_TESTS=1 make test) - Linting clean (
make format) - Security scan clean (snyk_code_scan, snyk_sca_scan)
- Documentation updated
Progress Tracking
| Step | Status | Notes |
|---|---|---|
| Step 1 | pending |
Session Log
Session 1 - [DATE]
Started: [time] Completed: [list of completed items] Next: [next steps for hand-off]
### Create Diagrams
1. Create mermaid files in `docs/diagrams/${issueID}_*.mmd`
2. Run: `make generate-diagrams`
3. Reference PNGs in implementation plan
### Get Confirmation
**Stop here.** Present the plan and wait for user confirmation before proceeding.
## Phase 3: Implementation (Outside-In TDD)
### CRITICAL: TDD is MANDATORY
**NEVER write production code before writing a failing test.**
This applies to:
- New features
- Bug fixes
- Security fixes
- Refactoring
- ANY code change
### TDD Gate Check
** ALWAYS use the testing skill. **
Before writing ANY production code, verify:
- [ ] **Test exists?** Have I written a test for this change?
- [ ] **Test fails?** Does the test fail without my change?
- [ ] **Test is specific?** Does the test target the exact behavior I'm changing?
**If ANY answer is NO → STOP and write the test first.**
### TDD Cycle
For each feature/change:
1. **STOP** - Do not touch production code yet
2. **READ and USE testing skill.**
2. **Write failing test first** (outside-in: ensure smoke tests. also write unit tests)
3. **Run test** - confirm it fails for the right reason
4. **Write minimal code** to make test pass
5. **Run test** - confirm it passes
6. **Refactor** if needed (tests must still pass)
### Commands
```bash
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 · 242 lines · 62 tokens per session scan A c90f7444729e
implementation is a skill published in the GitHub repository snyk/snyk-ls (82 stars, last pushed yesterday), licensed Apache-2.0. It adds 62 tokens to every session and 1,270 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-08-30.
Other skills, from other repositories
ui-animation
A test-first development method that requires a failing test before production code is written. TDD, or test-driven development, repeats a cycle of writing a test, making it pass, and then improving the code.
test-driven-development
A strict test-first method for implementing software changes: write a failing test, confirm that it fails, add the smallest code that passes, and then improve the code. TDD means test-driven development.
writing-plans
A guide for writing detailed implementation plans before changing code. It breaks a specification into small tasks, files to inspect or edit, and ways to test the result; TDD means writing tests before or alongside the code they check.
mirrord-prev-env
Help users create and manage mirrord preview environments — running a modified service as an isolated pod in a shared Kubernetes cluster, scoped by an environment key and HTTP/queue traffic filtering, so teams can validate and review changes against real traffic without affecting live services. Use when a developer…
engram-testing-coverage
TDD and coverage standards for Engram. Trigger: When implementing behavior changes in any package.
principle-test-behavior-not-implementation
Apply when you write, change, or keep a test. Assert what the code's users can observe, so that the test fails when that behavior breaks and keeps passing when only the internals change.