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 skills add ymd38/dev-skills --skill yds-vulnerability-scangit clone --depth 1 https://github.com/ymd38/dev-skillsWrote 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/ymd38/dev-skills/yds-vulnerability-scan)<a href="https://agentmods.dev/skills/ymd38/dev-skills/yds-vulnerability-scan"><img src="https://agentmods.dev/badge/skills/ymd38/dev-skills/yds-vulnerability-scan.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.00127 | $0.03347 |
| Opus 5 | $0.00063 | $0.01673 |
| Sonnet 5 | $0.00025 | $0.00669 |
| Haiku 4.5 | $0.00013 | $0.00335 |
Grade A, and why
yds-vulnerability-scan scanned grade A with 1 finding 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 6d 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.
Makes network callslowCapability
Not a fault in itself. Listed so you know the mod talks to something, and to what.
- All endpoints that fetch user-supplied URLs (`fetch(req.body.url)`, `requests.get(url)`) How it starts
The opening of the file, as written. The whole thing — 356 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Role: Offensive Security Auditor (Defense-Focused)
You perform systematic, evidence-based security audits with an attacker's mindset and a defender's output. Your findings are grounded in specific file/line citations. Every reported vulnerability has a clear attack path, a justified severity, and a concrete remediation recommendation. This is a read-only inspection — you do NOT modify any code.
Phase 1: Scope & Context
1.1 Pre-Scan Checklist
Before scanning, identify:
- Language & runtime — determines which injection patterns and tooling apply
- Trust boundaries — where does untrusted input enter the system? (HTTP params, headers, file uploads, message queues, webhooks)
- Authentication model — JWT, session cookies, API keys, OAuth?
- Data sensitivity — PII, financial data, credentials, health data?
- Deployment context — public internet? internal only? multi-tenant?
Context determines severity weighting. A missing HttpOnly flag on an internal admin tool is Medium; on a public banking app it is High.
1.2 Scan Strategy: Two Layers
Security audits require both automated scanning and manual review. Automated tools miss logic flaws; manual review misses patterns at scale. Do both.
Layer 1 — Automated (Semgrep)
semgrep --config auto --json --output semgrep-results.json .
Parse results and triage each finding as True Positive or False Positive (see triage guide in Phase 2).
Layer 2 — Manual Review After automated scanning, manually inspect the following high-risk areas that tools routinely miss:
- Authorization logic (can user A access user B's resources?)
- Business logic flows (can a free user access paid features?)
- Race conditions in state-changing operations
- Cryptographic implementation choices
- Third-party dependency audit:
npm audit/pip-audit/trivy/cargo audit
Phase 2: Vulnerability Checklist
Work through each category. For each, describe: what you searched for, what you found, and whether each finding is a true positive or false positive.
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.
- 6d ago First seen · 356 lines · 127 tokens per session scan A 23ea47c4e395
yds-vulnerability-scan is a skill published in the GitHub repository ymd38/dev-skills (4 stars, last pushed 9d ago), licensed MIT. It adds 127 tokens to every session and 3,347 once invoked, about $0.0006 per session on Opus 5. A static security scan graded it A with 1 finding (makes network calls). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
rest-api-design-patterns
Comprehensive guide for designing RESTful APIs including resource modeling, versioning strategies, HATEOAS, pagination, filtering, and HTTP best practices.
hive.chart-creation-foundations
Required reading whenever any chart tool is available. Teaches the one-tool embedding contract (call chartrender → live chart appears in chat AND a downloadable PNG lands in the queen session dir), the ECharts (data viz) vs Mermaid (structural diagrams) decision, the BI/financial-grade aesthetic baseline (no…
browser-edge-cases
SOP for debugging browser automation failures on complex websites. Use when browser tools fail on specific sites like LinkedIn, Twitter/X, SPAs, or sites with Shadow DOM.
shogun-screenshot
A screenshot tool for getting images from a computer or web page and then cropping, resizing, or masking sensitive information. Playwright is a browser-automation tool used here to capture web pages.
agent-qa-testing
Agent davranis testi ve protokol uyumluluk dogrulamasi. Agent'larin tanimli rollerine uygun davranip davranmadigini assertion-based test'lerle olcer. Personality drift, role violation ve output kalite regresyonu tespit eder.
review
Review the changes since a fixed point (commit, branch, tag, or merge-base) along two axes — Standards (does the code follow this repo's documented coding standards?) and Spec (does the code match what the originating issue/PRD asked for?). Runs both reviews in parallel sub-agents and reports them side by side. Use…