validate

validate is a skill for Claude Code from fubits1/svelte-skills. It costs 37 tokens per session (1,455 once invoked), scanned B, original, MIT.

A set of rules for checking code changes through browser checks, tests, screenshots, and CSS comparisons. It treats the working page as the final source of truth for interface changes.

In plain words
What is it for?
Use it before declaring work complete to inspect affected pages, take screenshots, measure or compare layouts, and repeat unstable Storybook or browser test suites.
Why use it?
It helps catch problems that linting or command-line tests may miss, including visual bugs and flaky browser tests.

Skill for Claude Code

Written for Claude Code: user-invocable in frontmatter. Also seen: mentions subagents.

Part of the frontend plugin — 13 skills shipped together

Good fit Use it before declaring work complete to inspect affected pages, take screenshots, measure or compare layouts, and repeat unstable Storybook or browser test suites.

Compare 6 skills from other repositories ↓
Install with agentmods
npx agentmods add skills/fubits1/svelte-skills/validate
Install

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.

Any agent
npx skills add fubits1/svelte-skills --skill validate
Clone the repo
git clone --depth 1 https://github.com/fubits1/svelte-skills

Made for: Claude Code.

Or install frontend, the plugin that ships this one along with the rest of its 13 skills.

Wrote 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.

agentmods badge for validate

README.md
[![agentmods](https://agentmods.dev/badge/skills/fubits1/svelte-skills/validate.svg)](https://agentmods.dev/skills/fubits1/svelte-skills/validate)
Your own site
<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>
Per session 37 Skills are progressive disclosure: only the name and description are preloaded; the body loads when the skill is used.
When invoked 1,455 The whole file, excluding the scripts and references it only reads on demand.
Security scan B 1 finding. A grade says what 26 rules found in the file — not that it is safe.
Origin original No closer match found in the catalogue.
Token cost

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.

ModelPer sessionOnce 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

Measured 8d ago against content hash 0643be98d1a8, method: parsed. Prices are Anthropic first-party input rates as of 2026-09-08, from the pricing page.

Security

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
plugins/frontend/skills/validate/SKILL.md · 42 lines

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:playwright skill for all rules on screenshots, critical examination, browser_evaluate measurements, 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/.vite and node_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 test also launches e2e tests which need a dev server: use pnpm test:unit for quick feedback.
  • Test in the correct mode: dev changes to pnpm dev, not pnpm 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:playwright skill).
  • pnpm test does 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 validate exists 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 check alone does NOT catch TS2448/TS2454 (block-scoped variable used before declaration). tsgo --noEmit does. This script covers both.
  • .svelte, .svelte.ts, .svelte.js files: ALWAYS run the Svelte autofixer (mcp__svelte__svelte-autofixer) after editing to validate Svelte 5 correctness. (pnpm lint:file already includes this.)
  • CI workflow changes: simulate the CI environment locally before pushing. Run commands with CI=true GITHUB_ACTIONS=true to 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 .yml workflow file. Exit code 0 or it's not valid.
  • Use pnpm validate:build as 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, run pnpm test:unit. pnpm validate only 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:build exit 0? CI workflows edited to pnpx node-actionlint?
  • 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 having broken something. Never tell the user "I didn't change that" without checking git first.

Read the full file on GitHub · 42 lines

Changes

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.

  1. 8d ago First seen · 42 lines · 37 tokens per session scan B 0643be98d1a8

Subscribe to this mod's changes

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.

Related

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.

davila7/claude-code-templates · 43 tokens

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".

apache/tika · 50 tokens

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…

neuron-core/neuron-ai · 77 tokens

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.

NVIDIA/skills · 50 tokens

atmos-validation

Validate Atmos projects, components, arbitrary JSON Schema inputs, EditorConfig, and GitHub Actions; use affected-file selection and native CI annotations.

cloudposse/atmos · 31 tokens

skill-benchmark

Benchmark AI skill effectiveness by measuring implementation quality against legacy constraints.

HoangNguyen0403/agent-skills-standard · 16 tokens