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 agentmods add skills/snyk/snyk-ls/implementationnpx skills add snyk/snyk-ls --skill implementationgit 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.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 | $0.00062 | $0.01270 |
| Opus 5 | $0.00031 | $0.00635 |
| Sonnet 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 4d 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.
- 4d ago First seen · 242 lines · 62 tokens per session scan A c90f7444729e
implementation is a skill published in the GitHub repository snyk/snyk-ls (83 stars, last pushed today), licensed Apache-2.0. It adds 62 tokens to every session and 1,270 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
launch
Launch and automate VS Code (Code OSS) using agent-browser via Chrome DevTools Protocol. Use when you need to interact with the VS Code UI, automate the chat panel, test UI features, or take screenshots of VS Code. Triggers include 'automate VS Code', 'interact with chat', 'test the UI', 'take a screenshot', 'launch…
accessibility
Primary accessibility skill for VS Code. REQUIRED for new feature and contribution work, and also applies to updates of existing UI. Covers accessibility help dialogs, accessible views, verbosity settings, signals, ARIA announcements, keyboard navigation, and ARIA labels/roles.
sessions
Agent Sessions window architecture — covers the sessions-first app, layering, folder structure, chat widget, menus, contributions, entry points, and development guidelines. Use when implementing features or fixing issues in the Agent Sessions window.
component-fixtures
Use when creating or updating component fixtures for screenshot testing, or when designing UI components to be fixture-friendly. Covers fixture file structure, theming, service setup, CSS scoping, async rendering, and common pitfalls.
tool-rename-deprecation
Ensure renamed built-in tool references preserve backward compatibility. Use when renaming a toolReferenceName, tool set referenceName, or any tool identifier. Run on ANY change to tool registration code. Covers legacyToolReferenceFullNames for tools and legacyFullNames for tool sets.
author-contributions
Identify all files a specific author contributed to on a branch vs its upstream, tracing code through renames. Use when asked who edited what, what code an author contributed, or to audit authorship before a merge. This skill should be run as a subagent — it performs many git operations and returns a concise table.