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 metraton/gaia --skill gaia-verifygit clone --depth 1 https://github.com/metraton/gaiaWrote 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/metraton/gaia/gaia-verify)<a href="https://agentmods.dev/skills/metraton/gaia/gaia-verify"><img src="https://agentmods.dev/badge/skills/metraton/gaia/gaia-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/metraton/gaia/gaia-verify"><img src="https://agentmods.dev/badge/skills/metraton/gaia/gaia-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.00033 | $0.02337 |
| Opus 5 | $0.00016 | $0.01169 |
| Sonnet 5 | $0.00007 | $0.00467 |
| Haiku 4.5 | $0.00003 | $0.00234 |
Grade B, and why
gaia-verify 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 yesterday.
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.
Reads agent configuration directoriesmediumAgent snooping
.claude/, .codex/, .gemini/ hold keys, settings and other credentials a mod has no legitimate need for.
2. `cat <workspace>/.claude/plugin-registry.json` -- `installed[].name` at the expected version. **Decided:** the canonical registry identity is `gaia` (`_read_plugin_name` in `_install_helpers.py` strips the npm scope f How it starts
The opening of the file, as written. The whole thing — 110 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Gaia Verify
Confirm that a Gaia installation actually works. Given a workspace and a delivery surface, run the checks that match that surface and report PASS/FAIL. This skill owns the definition of "a healthy install" -- the wire-up checklist and the per-surface checks. It is the check that gaia-release calls at the close of every layer; here it stands alone so the user can invoke it directly against whatever they just installed.
Gaia ships as one tree reaching a workspace through two surfaces -- npm/pnpm (the npm package @jaguilar87/gaia: symlinks + settings.local.json) and the Claude Code plugin (source: github with a pinned ref -- .claude-plugin/marketplace.json advertises the plugin, so /plugin install makes CC clone the git repo into its plugin cache and load hooks from the repo root's hooks/hooks.json; the root .claude-plugin/plugin.json is metadata-only, and there is no dist/ bundle). A change can pass on one surface and break on the other, so the mode you pick must match the surface you are validating.
Decision tree
"probemos" / "verify" / "test installation"
├─ Already installed in a workspace (npm/pnpm), just edited source? -> live
├─ Proving the npm tarball before a release? -> npm-sandbox
├─ Proving the npm tarball as a plugin before a release? -> plugin
└─ Confirming a version already published to npm? -> registry
If the user does not name a mode, ask: "Which mode -- live, npm-sandbox, plugin, or registry?"
Mode: live
Validates a workspace that is already wired (npm/pnpm surface). No build, no temp dir, no cleanup.
Run against the workspace: gaia doctor then gaia status, then the wire-up checklist below. This is the mode gaia-release Layer 1 and Layer 3 call after installing into the target (via gaia dev --workspace <TARGET>, the one-command install).
Mode: npm-sandbox
Validates the npm surface of exactly what a registry publish would ship -- pack, install into a clean sandbox, run the harness, clean up. No accumulated workspace state.
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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.
- yesterday Changed 2b500eb0ce6a
- 10d ago First seen · 110 lines · 33 tokens per session scan B e97f2e13f1d0
gaia-verify is a skill published in the GitHub repository metraton/gaia (3 stars, last pushed today), licensed MIT. It adds 33 tokens to every session and 2,337 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it B with 1 finding (reads agent configuration directories). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
smoke
Runs a three probe live smoke wave after a plugin update and reports gate chain health before real work rides it.
swarm-pi-discover
Investigate unknown requirements or unresolved technical claims through Pi's fixed research, experiment, and convergence sequence. Use when reproducible evidence and Human Decision gates are required; route one answer to ask and evidence-ready design to plan.
test-driven-development
Use when implementing any feature or bugfix, before writing implementation code - write the failing test first and watch it fail for the right reason.
ac-writer
Use as the first phase of a wave. Drafts brutal, testable acceptance criteria for a feature. Each AC must be falsifiable by a real-world test. Output written to .wave/ac.md.
teet-verify
Use only after the user has approved the GREEN screenshot. Performs True End-to-End Testing across backend, frontend, DB, and external services with computed-style and boundingBox assertions, producing the final wave evidence pack.
wave-execution-framework-v2
Use when executing multi-wave engineering work needing strict TDD, bug-capture/fix split, quality gates, and orchestrated teams with per-agent Opus-advisor / Sonnet-executor model routing.