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 kensaurus/cursor-kenji --skill plan-input-validationgit clone --depth 1 https://github.com/kensaurus/cursor-kenjiWrote 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/kensaurus/cursor-kenji/plan-input-validation)<a href="https://agentmods.dev/skills/kensaurus/cursor-kenji/plan-input-validation"><img src="https://agentmods.dev/badge/skills/kensaurus/cursor-kenji/plan-input-validation/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/kensaurus/cursor-kenji/plan-input-validation"><img src="https://agentmods.dev/badge/skills/kensaurus/cursor-kenji/plan-input-validation.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector warn
SkillSpector: 1 finding, up to medium
These are SkillSpector’s own severities. On a checked sample its high-severity flags on skills were ~96% false positives — a documented command, a public API, a “never do X” rule — so we show them as a caution to read, not a verdict. Why →
- medium Excessive Agency · line 91 Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.Fix: Add human-in-the-loop confirmation for destructive, irreversible, or high-impact operations. Never auto-execute commands that modify files, send data, or alter system state.
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.01983 |
| Opus 5 | $0.00031 | $0.00992 |
| Sonnet 5 | $0.00012 | $0.00397 |
| Haiku 4.5 | $0.00006 | $0.00198 |
Grade A, and why
plan-input-validation 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 5d 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 — 181 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Input-Validation & Trust-Boundary Audit + Hardening Plan
Degree of freedom: HIGH — map trust boundaries, score gaps, emit a plan. Stay plan-only. No Zod, sanitizers, or webhook edits until approved.
This skill vs neighbors
| Skill | Owns |
|---|---|
| plan-input-validation (this) | Trust-boundary / injection plan |
enhance-web-forms |
Apply production form quality |
plan-security-audit |
OWASP umbrella burndown |
Role: Senior application security engineer (trust-boundary lens).
Task: Map every point untrusted data enters, score validate/sanitize/authenticate
gaps, phase remediations, emit plan-input-validation.md. Audit & plan only — no
code changes until each phase is approved.
Walk every boundary. Find what's trusted that shouldn't be. Change nothing until approved.
How to reason (every plan item)
- Propose — schema, sanitize, signature verify, or allowlist
- Risk — forgeable money/data, stored XSS, or injection
- Keep-working — boundaries that already validate + authenticate
- Phase — Forgeable paths → XSS → Schema pass → Uploads (do not execute)
Worked example
Propose: verify the Stripe webhook with
constructEventon the raw body; reject empty secrets; return 400 on bad signatures. Risk: empty-signing-secret bypass — anyone can forgeinvoice.paidand credit quota. Keep-working: checkout session creation already uses the server-side secret. Phase: Phase 1 — Forgeable money/data paths. Note: origin proof ≠ safe to interpolate into SQL/HTML.
AI agents write code that works on the inputs you showed them. Two signature patterns
recur: dangerouslySetInnerHTML without DOMPurify (XSS), and webhook handlers without
real signature verification — the reported empty-signing-secret bypass class, where an
empty secret lets any attacker forge valid signatures and credit unlimited quota
without payment.
This skill is the audit-and-plan half. Execution goes to backend-patterns /
backend-error-handling / audit-security after you approve each phase.
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.
- 5d ago First seen · 181 lines · 62 tokens per session scan A 93b2bb8500f9
plan-input-validation is a skill published in the GitHub repository kensaurus/cursor-kenji (9 stars, last pushed 11d ago), licensed MIT. It adds 62 tokens to every session and 1,983 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-09-03.
Other skills, from other repositories
firebase-auth
Use when setting up auth, managing auth state, implementing email/password or social sign-in, handling auth errors, or managing users.
firebase-cloud-functions
Use when calling callable functions (httpsCallable), passing data to server-side logic, handling function errors/timeouts, configuring regions, or testing with the Emulator Suite.
031-architecture-adr-functional-requirements
Facilitates conversational discovery to create Architectural Decision Records (ADRs) for functional requirements covering CLI, REST/HTTP APIs, or both. Use when the user wants to document command-line or HTTP service architecture, capture functional requirements, create ADRs for CLI or API projects, or design…
302-frameworks-spring-boot-rest
Use when you need to design, review, or improve REST APIs with Spring Boot — including HTTP methods, resource URIs, status codes, DTOs, versioning, deprecation and sunset headers, content negotiation (JSON and vendor media types), ISO-8601 instants in DTOs, pagination/sorting/filtering, Bean Validation at the…
305-frameworks-spring-boot-modulith
Use when you need to design, review, or improve modular monoliths with Spring Modulith in Spring Boot applications - including application module package structure, ApplicationModules verification, named interfaces, allowed dependencies, domain events, @ApplicationModuleTest, Scenario-based module tests, generated…
401-frameworks-quarkus-core
Use when building or reviewing core Quarkus applications with CDI beans and scopes, SmallRye Config and profiles, lifecycle, interceptors and events, virtual threads, and test-friendly design. This should trigger for requests such as Review Java code for Quarkus application structure and CDI; Apply best practices for…