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/thejefflarson/soundcheck/csrfnpx skills add thejefflarson/soundcheck --skill csrfgit clone --depth 1 https://github.com/thejefflarson/soundcheckWhat 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.00056 | $0.00731 |
| Opus 5 | $0.00028 | $0.00365 |
| Sonnet 5 | $0.00011 | $0.00146 |
| Haiku 4.5 | $0.00006 | $0.00073 |
Grade A, and why
csrf 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 2d 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 — 64 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Cross-Site Request Forgery Check (A01:2025)
What this checks
Protects against cross-site request forgery, where an attacker tricks an authenticated user's browser into submitting a state-changing request the user did not intend. Exploitation leads to unauthorized fund transfers, account takeover, or privilege escalation.
Vulnerable patterns
- HTML form posting a state-changing request with no CSRF token hidden field
- Framework CSRF protection explicitly disabled or exempted on a state-changing endpoint
- Session cookie issued without a
SameSiteattribute (LaxorStrict) - Web app with no CSRF middleware registered for cookie-authenticated state-changing routes
- Cookie-authenticated API endpoint accepting POST/PUT/PATCH/DELETE with no token check
Fix immediately
Flag the vulnerable code and explain the risk. Then suggest a fix that establishes these properties:
- Every state-changing endpoint (POST/PUT/PATCH/DELETE) validates a per-session or per-request CSRF token server-side before any mutation. Use the framework's documented CSRF middleware — do not roll your own.
- Framework CSRF protection is never disabled or exempted on a state-changing
route. If a route legitimately needs to opt out (a pure JSON API authenticated
by
Authorization: Bearerheaders, not cookies), the opt-out must be explicit and the cookie-auth path must remain protected. - Session cookies carry
SameSite=Laxat minimum, orSameSite=Strictfor sensitive flows, plusSecureandHttpOnly. This blocks cross-origin cookie attachment on top-level navigations or subrequests that don't need it. - CSRF tokens are not exposed in URLs, logs, or
Refererheaders — they live in a hidden form field or a dedicated request header, never in the query string. - Forms include the token via the framework's template helper, so the token binds to the session and is rotated as the framework intends.
Translate these principles to the audited file's language and framework. Use the documented CSRF middleware and template helpers for that stack — do not hand-build token comparison logic.
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.
- 2d ago First seen · 64 lines · 56 tokens per session scan A 5f9af629fb40
csrf is a skill published in the GitHub repository thejefflarson/soundcheck (20 stars, last pushed 1mo ago), licensed MIT. It adds 56 tokens to every session and 731 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
dingtalk_channel_connect
Use a headed browser to automatically complete DingTalk channel integration for QwenPaw. Applicable when the user mentions DingTalk, developer console, Client ID, Client Secret, bot, Stream mode, binding or configuring a channel. Supports pausing when a login page is detected and resuming after the user logs in.
dingtalk_channel_connect
使用可视浏览器自动完成 QwenPaw 的钉钉频道接入。适用于用户提到钉钉、DingTalk、开发者后台、Client ID、Client Secret、机器人、Stream 模式、绑定或配置 channel 的场景；支持遇到登录页时暂停，等待用户登录后继续。.
browser_cdp
Use this skill when the user explicitly wants to connect to a running Chrome browser, scan local CDP ports, specify a cdpport, or share a single browser across multiple agents/tools. By default browser opens no debugging port; pass an explicit cdpport only when the user wants another local tool to attach.
browser_cdp
当用户明确希望连接到已运行的 Chrome 浏览器、扫描本地 CDP 端口、显式指定 cdpport，或让多个 agent / 工具共享同一个浏览器时，使用本 skill。browser 默认不开放调试端口；仅当用户明确希望其他本地工具附加时才显式传入 cdpport。.
browser_visible
当用户需要控制 browser 的浏览器启动方式时，使用本 skill。browser 默认由 Playwright 直接管理、不开放调试端口（需让其他本地工具附加时显式传 cdpport）；headed 控制是否显示窗口，privatemode 保留用于兼容、不再改变默认行为，browserargs 传入额外的 Chromium 启动参数，executablepath 指定自定义浏览器可执行文件路径。.
browser_visible
Use this skill when the user needs to control the browser launch mode for browser. By default browser is managed by Playwright and opens no debugging port (pass an explicit cdpport to let another local tool attach); headed controls whether the window is visible, and privatemode is kept for backward compatibility and…