Borrowing it
Nothing to install: this file belongs to nodealchemy/powernode-platform. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/nodealchemy/powernode-platform/develop/.claude/skills/verify/SKILL.mdgit clone --depth 1 https://github.com/nodealchemy/powernode-platformWrote 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/nodealchemy/powernode-platform/verify)<a href="https://agentmods.dev/skills/nodealchemy/powernode-platform/verify"><img src="https://agentmods.dev/badge/skills/nodealchemy/powernode-platform/verify/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/nodealchemy/powernode-platform/verify"><img src="https://agentmods.dev/badge/skills/nodealchemy/powernode-platform/verify.svg" alt="Reviewed on agentmods" width="80" 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.00012 | $0.00845 |
| Opus 5.5 | $0.00005 | $0.00338 |
| Sonnet 5.5 | $0.00002 | $0.00169 |
| Haiku 4.5 | $0.00001 | $0.00085 |
Grade A, and why
verify 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 1mo 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 — 97 lines — stays where its author put it; the contents beside it link to each section on GitHub.
/verify — Targeted Change Verification
Run focused quality checks based on what actually changed. Faster than validate.sh, more thorough than hooks.
Step 1: Detect Changes
If scope is auto or no argument provided, detect what changed:
# Changed Ruby files (unstaged + staged + untracked)
git diff --name-only HEAD -- '*.rb' 2>/dev/null
git diff --cached --name-only -- '*.rb' 2>/dev/null
git ls-files --others --exclude-standard -- '*.rb' 2>/dev/null
# Changed TypeScript files
git diff --name-only HEAD -- '*.ts' '*.tsx' 2>/dev/null
git diff --cached --name-only -- '*.ts' '*.tsx' 2>/dev/null
git ls-files --others --exclude-standard -- '*.ts' '*.tsx' 2>/dev/null
# Changed migrations and seeds
git diff --name-only HEAD -- 'server/db/migrate/' 2>/dev/null
git diff --name-only HEAD -- 'server/db/seeds/' 2>/dev/null
If a specific scope is given (ruby, typescript, migration, seed), only run that category.
Step 2: Ruby Verification (if .rb files changed)
- Syntax check all changed
.rbfiles:ruby -c <file> # for each changed file - Find related specs: Map each changed source file to its spec:
app/models/foo.rb→spec/models/foo_spec.rbapp/services/foo.rb→spec/services/foo_spec.rbapp/controllers/api/v1/foo_controller.rb→spec/requests/api/v1/foo_spec.rborfoo_controller_spec.rb
- Run related specs (only those that exist):
cd server && bundle exec rspec <spec-files> --format progress
Step 3: TypeScript Verification (if .ts/.tsx files changed)
- Type check the full frontend project:
cd frontend && npx tsc --noEmit - Find related tests: Look for
*.test.tsor*.test.tsxalongside changed files - Run related tests (if they exist):
cd frontend && CI=true npm test -- --testPathPatterns "<pattern>" --watchAll=false
Step 4: Migration Verification (if migration files changed)
- Check migration status:
cd server && bundle exec rails db:migrate:status - If any migrations are
down, run them:cd server && bundle exec rails db:migrate
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.
- 1mo ago Changed 50f311adbe3b
- 2mo ago First seen · 97 lines · 12 tokens per session scan A 686702202766
verify is a skill published in the GitHub repository nodealchemy/powernode-platform (4 stars, last pushed 5d ago), licensed MIT. It adds 12 tokens to every session and 845 once invoked, about $0.0000 per session on Opus 5.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-31.
Other skills, from other repositories
agent-evals
A method for testing AI agents by examining what they actually did during a run, including their tool use and execution steps. It also covers building test cases from real production runs and comparing automated judgments with human labels.
agent-puzzles
Competitive puzzle arena for AI agents with timed solving, per-model leaderboards, and 5 categories (reverse captcha, geolocation, logic, science, code). Use when solving puzzles, tracking rankings, creating new challenges, or benchmarking agent capabilities.
benchmark-critic
Evaluate benchmark design for fair baselines, measurable outcomes, leakage, cherry-picking, and reproducibility.
release-readiness
Check whether a change is ready for a public release candidate across packaging, docs, tests, and rollback risk.
ev-benchmark-verification
Phase 2B of the Gaia evidence verification pipeline. Verifies benchmark-result rows and benchmark-source candidates against registry/benchmark-sources.json before adversarial audit, link validation, catalog promotion, or ingestion. Use when running /ev-pipeline, checking benchmark-result evidence, reviewing…
fp-review
Adversarially review the full relevant PR diff with isolated probes and meaningful before/after checks. Use for "review the PR", "sandbox review", or the review stage; retain required reviewer independence and report self- review limits honestly.