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 fubits1/svelte-skills --skill validategit clone --depth 1 https://github.com/fubits1/svelte-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/fubits1/svelte-skills/validate)<a href="https://agentmods.dev/skills/fubits1/svelte-skills/validate"><img src="https://agentmods.dev/badge/skills/fubits1/svelte-skills/validate.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.00037 | $0.01455 |
| Opus 5 | $0.00018 | $0.00727 |
| Sonnet 5 | $0.00007 | $0.00291 |
| Haiku 4.5 | $0.00004 | $0.00145 |
Grade B, and why
validate scanned grade B 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 8d 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.
Subtle steeringmediumPrompt injection
Instructions that bias recommendations or shape behaviour without the user noticing.
- **NEVER trust subagent claims.** After EVERY subagent completes, run `git diff` to see what actually changed. Subagents can claim "done, no changes needed" while having silently modified files, or claim "fixed" while h How it starts
The opening of the file, as written. The whole thing — 42 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Validation
- Browser FIRST. Before running any CLI validation, verify your changes work in the browser via Playwright. Navigate to affected pages, confirm the feature works, take screenshots. Broken code that passes lint is still broken. Browser is the source of truth.
- Browser verification: see
frontend:playwrightskill for all rules on screenshots, critical examination,browser_evaluatemeasurements, and visual debugging. NEVER ask the user to check their browser: that is YOUR job. - FLAKY SUITES NEED MULTIPLE RUNS. Storybook/browser/e2e/MSW tests are flaky on a single run. Before declaring green, run 3x in a row from a clean state: kill the test server port, delete
node_modules/.viteandnode_modules/.cache/storybook, then run. ALL three must pass. One green run is meaningless. - SETUP TIME VARIANCE IS A FLAKE FLAG. If the same suite shows setup time varying by >30% between runs (e.g. 100s vs 200s), the runs are not equivalent: one of them is silently skipping imports. Do not trust either count until you understand why.
- MATCH THE USER'S RUN CONDITIONS. When the user reports a failing run, reproduce their EXACT state before claiming a fix worked: same branch, same lockfile, same cache state. If I cannot reproduce their failure, I say so out loud: I do not paper over it with my own green output from a different cache state.
Test Files N passed (N)≠ verification. Always cross-check the test count against the expected total. A run that "passes 85/85" but only executes 147 of 192 tests has silently skipped 24% of the suite.- Before declaring done/fixed: run
pnpm validate(vitest + lint + typecheck + svelte-check). Must exit 0. Exception: pure CSS-only changes don't need a build: verify visually via Playwright instead and lint / vitest / svelte-check. - Run
pnpm test:unit(vitest) after every change.pnpm testalso launches e2e tests which need a dev server: usepnpm test:unitfor quick feedback. - Test in the correct mode: dev changes to
pnpm dev, notpnpm build. - Exit code 0 or it's not verified. Crashes ≠ passes.
- Crashed baseline ≠ valid baseline. Incomplete runs have meaningless timing.
- Timed-out command = failed verification. Task is NOT done.
- Single-file success ≠ full-run success. Always run the full command.
- Get a baseline BEFORE making config changes, then compare.
- Never declare "done" when error counts drop. Compare rule-by-rule.
- Unit tests prove nothing about component APIs: verify in browser (see
frontend:playwrightskill). pnpm testdoes NOT verify MSW handlers, fixtures, or Storybook rendering. Those need the storybook project and a browser check (svelte-5:msw,svelte-5:storybook-vitest).- If
pnpm validateexists in package.json, run it as the final verification step. It combines vitest + lint + typecheck + svelte-check. - When fixing a bug found via browser interaction: reproduce the exact user flow via Playwright BEFORE declaring done.
- Never declare "done" when verification failed or was skipped.
- Show proof, not summaries.
- VALIDATE AFTER EVERY SINGLE FILE EDIT. Not after a batch. Edit one file, run checks, confirm 0 errors, then move to next file. NEVER batch edits across multiple files without validating between them.
pnpm lint:file <file>: run this on every edited file. It runs eslint + oxlint + tsgo (filtered to that file) + svelte-autofixer in one command.pnpm checkalone does NOT catch TS2448/TS2454 (block-scoped variable used before declaration).tsgo --noEmitdoes. This script covers both..svelte,.svelte.ts,.svelte.jsfiles: ALWAYS run the Svelte autofixer (mcp__svelte__svelte-autofixer) after editing to validate Svelte 5 correctness. (pnpm lint:filealready includes this.)- CI workflow changes: simulate the CI environment locally before pushing. Run commands with
CI=true GITHUB_ACTIONS=trueto catch tools that auto-detect CI and change behavior (e.g. oxlint switches to--format=github). NEVER push a CI "fix" without local CI simulation first. - GitHub Actions workflow files: ALWAYS run
pnpx node-actionlint <file>after editing any.ymlworkflow file. Exit code 0 or it's not valid. - Use
pnpm validate:buildas the final verification: runs validation and build tasks concurrently. See SETUP.md for how to configure this script. One command, everything checked. - Run the TEST TYPE you changed. If you modified Playwright tests, run
pnpm test:e2e. If you modified vitest tests, runpnpm test:unit.pnpm validateonly runs vitest: it does NOT run Playwright e2e. Changed tests must actually execute and pass. - LINT TEST FILES:
pnpm lint:tests. One command, runs all 5 linters (oxlint, tsgo, eslint, knip, svelte-check) on test files concurrently. Must exit 0. Do NOT run individual linters: you WILL forget one. - One problem at a time. Fix ONE problem, verify it passes, then move to the next. Never batch unrelated changes: changing two things at once makes it impossible to tell which change broke what.
- Capture expensive test output. When running Playwright or e2e tests, pipe to
tee /tmp/test-output.log. If output is already in context, READ IT: never rerun. NEVER run the same expensive command twice in a row just to grep differently. - Final checklist before declaring done: Browser verified? Linted?
pnpm validate:buildexit 0? CI workflows edited topnpx node-actionlint? - NEVER trust subagent claims. After EVERY subagent completes, run
git diffto see what actually changed. Subagents can claim "done, no changes needed" while having silently modified files, or claim "fixed" while having broken something. Never tell the user "I didn't change that" without checking git first.
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.
- 8d ago First seen · 42 lines · 37 tokens per session scan B 0643be98d1a8
validate is a skill published in the GitHub repository fubits1/svelte-skills (10 stars, last pushed 1mo ago), licensed MIT. It adds 37 tokens to every session and 1,455 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it B with 1 finding (subtle steering). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
research-engineer
An uncompromising Academic Research Engineer. Operates with absolute scientific rigor, objective criticism, and zero flair. Focuses on theoretical correctness, formal verification, and optimal implementation across any required technology.
tika-eval-compare
Compare extracts from two Tika builds over a corpus to detect regressions in content, encoding, exceptions, and embedded-document handling. Use for "compare before/after extracts", "eval this change against the corpus".
neuron-evaluation-engineer
Create and run AI evaluations with datasets, assertions, and output drivers in Neuron AI. Use this skill whenever the user mentions evaluation, testing AI systems, creating evaluators, dataset-driven testing, assertion-based validation, or wants to measure AI system performance. Also trigger for tasks involving…
jetson-validate-image
Use after jetson-flash-image to run static BSP checks, on-target smoke/regression tests on a flashed DUT, or both. Not for build or flash steps. Triggers: validate bsp, on-target validation.
atmos-validation
Validate Atmos projects, components, arbitrary JSON Schema inputs, EditorConfig, and GitHub Actions; use affected-file selection and native CI annotations.
skill-benchmark
Benchmark AI skill effectiveness by measuring implementation quality against legacy constraints.