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 helderberto/agent-skills --skill checkgit clone --depth 1 https://github.com/helderberto/agent-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/helderberto/agent-skills/check)<a href="https://agentmods.dev/skills/helderberto/agent-skills/check"><img src="https://agentmods.dev/badge/skills/helderberto/agent-skills/check/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/helderberto/agent-skills/check"><img src="https://agentmods.dev/badge/skills/helderberto/agent-skills/check.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.00070 | $0.00656 |
| Opus 5.5 | $0.00028 | $0.00262 |
| Sonnet 5.5 | $0.00014 | $0.00131 |
| Haiku 4.5 | $0.00007 | $0.00066 |
Grade A, and why
check 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 3d 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 — 40 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Check
Run the project's own quality gates — format/lint fix, type check, tests — whatever this project defines. Detect the toolchain; never assume npm. Lint-only ask → steps 1–3, skip tests. --check or check-only wording ("check lint", "run the linter" without "fix") → skip step 2, so no file is written.
Workflow
- Detect the project's commands. Prefer a task the project already defines over a raw tool call:
- Node →
package.jsonscripts (lint:fix/lint-fix,lint,typecheck/tsc,test) - Python →
pyproject.toml/tox.ini/Makefile(ruff --fix/black,ruff/flake8,mypy,pytest) - Go →
gofmt -w,golangci-lint run/go vet,go build ./...,go test ./... - Rust →
cargo fmt,cargo clippy,cargo check,cargo test - else → read the
Makefile/ CI config for the equivalent targets
- Node →
- Format + lint fix (the fix variant). These rewrite files in place and exit 0 silently — capture what changed right after (
git status --short/git diff --stat) and remember it for the report. The user is about to commit; they need to know their tree was modified. - Lint + types (check variants).
- Tests.
- Report: an Auto-fixed section listing files the fix step changed (or "nothing auto-fixed"), then overall PASS or FAIL with
file:lineerror references.
Rules
- Detect the project's commands — never hardcode a package manager
- Auto-fix before reporting errors, unless
--check— but never modify files silently; always report which files auto-fix changed - Run fix → check → test sequentially
- If the fix step fails, still run check + tests; report all failures at the end
- Report errors as
file:linereferences - Never commit, stage, or push anything
Error Handling
- If no recognizable manifest/tasks → ask the user for the validate command, or report and stop
- If a step's command doesn't exist → skip it, note it was skipped
- If all steps missing → report nothing to run, stop
- If tests time out → report and suggest raising the runner's timeout
- If a runner crashes (exit code other than 0 or 1) → report crash output and stop
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.
- 3d ago Changed · +8 tokens per session f27e35edd6f0
- 15d ago First seen · 40 lines · 62 tokens per session scan A fffb45b4577f
check is a skill published in the GitHub repository helderberto/agent-skills (19 stars, last pushed today), licensed MIT. It adds 70 tokens to every session and 656 once invoked, about $0.0003 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-10-12.
Other skills, from other repositories
test-driven-development
Drives development with tests using the red-green-refactor loop. Use when implementing any logic, fixing any bug, or changing any behavior. Use when you need to prove that code works, when a bug report arrives, or when you're about to modify existing functionality. Use when asked to add tests to a function, fix a bug…
browser-testing-with-devtools
Tests in real browsers via Chrome DevTools MCP. Use when building or debugging anything that runs in a browser. Use when you need to inspect the DOM, capture console errors, analyze network requests, profile performance, or verify visual output with real runtime data. Requires the chrome-devtools MCP server to be…
test-driven-development
Red-green-refactor cycle with meaningful coverage. Tests are written before implementation. Coverage is a side effect of good tests, not the goal.
integration-testing
Test real system boundaries, not mocks of mocks. Integration tests verify that components work together, not that they work in isolation.
constraint-driven-development
A development method for writing a project's quality standards as a lasting, checkable contract. It can cover areas such as test coverage, security, performance, accessibility, and architecture.
test-driven-development
Instructions for test-driven development, or TDD: writing a failing test first, then the smallest code that makes it pass, followed by cleanup.