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 wellwelwel/lagune --skill lagune.provegit clone --depth 1 https://github.com/wellwelwel/laguneWrote 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/wellwelwel/lagune/lagune.prove)<a href="https://agentmods.dev/skills/wellwelwel/lagune/lagune.prove"><img src="https://agentmods.dev/badge/skills/wellwelwel/lagune/lagune.prove/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/wellwelwel/lagune/lagune.prove"><img src="https://agentmods.dev/badge/skills/wellwelwel/lagune/lagune.prove.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.00055 | $0.03993 |
| Opus 5.5 | $0.00022 | $0.01597 |
| Sonnet 5.5 | $0.00011 | $0.00799 |
| Haiku 4.5 | $0.00006 | $0.00399 |
Grade A, and why
lagune.prove 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 — 207 lines — stays where its author put it; the contents beside it link to each section on GitHub.
User Input
$ARGUMENTS
The User Input above decides how this command runs. Read it before proceeding.
Outline
You are producing proofs under .lagune/proofs/: for each detected finding you can demonstrate, a runnable test and a self-contained advisory that a maintainer can take into responsible disclosure. The detect map at .lagune/memory/detect.md is the primary input, and every proof points back at a finding that map really carries.
This command is optional and autonomous. It is not one of the five phases and not part of the tracking chain. It writes only into .lagune/proofs/, and it is read-only on the reconciled phase artifacts (detect.md, plan.md, harden.md, charter.md) and on the user's source under test. Only verify writes across the chain, so this command never removes or rewrites a finding.
Each proof is two things, kept as a unit in its own directory:
- A test that asserts the safe path: it expects success on the secure behavior, so it fails while the issue persists and passes once the code is fixed. This is defensive regression evidence, never an exploit or an attack payload. The test comes first, it is the evidence that actually runs.
- A self-contained advisory the user can paste straight into a private GitHub Gist per vulnerability, so it never relies on a parent README or sibling files. Its Proof of Concept is a runnable reproduction through the project's public API, derived from the test and written only after it: a reviewer copies the block, runs it, and sees the symptom from the code's own output, the way a disclosure report shows the path a user reaches the issue through.
Step 1: Decide the scope from the input
The User Input above selects one of three modes:
- No input (the User Input is empty): prove every finding in the detect map.
- Findings, files, or directories given (the input names one or more finding names from the map, or paths in the project): prove only the matching findings. Match a name to the map's findings, and match a path to the findings through the tracking map (
.lagune/tracking.json), which records the paths each finding points at. Leave the rest untouched. - A concern described (the input describes what to focus on, for example "the SQL handling"): prove only the findings that touch that concern.
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.
- 3d ago First seen · 207 lines · 55 tokens per session scan A 5dadab3b43ac
lagune.prove is a skill published in the GitHub repository wellwelwel/lagune (173 stars, last pushed 2d ago), licensed Apache-2.0. It adds 55 tokens to every session and 3,993 once invoked, about $0.0002 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-26.
Other skills, from other repositories
octocode-benchmark
Use when planning, running, grading, or reporting the by-hand Octocode research benchmark — pairwise matchups (Octocode anchor vs one baseline: gh+RTK, gh+Headroom, or plain gh) over markdown questions, with a fresh isolated runner agent per (question, arm, pass), one blind judge per question grading two answers X/Y…
112-java-maven-plugins
Use when you need to add or configure Maven plugins in your pom.xml — including quality tools (enforcer, surefire, failsafe, jacoco, pitest, spotbugs, pmd), security scanning (OWASP), code formatting (Spotless), version management, container image build (Jib), build information tracking, and benchmarking (JMH) …
patrol-e2e-testing
Use when writing E2E/integration tests, testing native interactions like permissions or system dialogs, capturing UI regressions, or validating cross-platform behavior (Patrol 4.x).
testing
Use when writing or reviewing Flutter/Dart tests (unit, widget, golden), fixing flaky tests, adding coverage, or choosing between unit and widget tests.
mockito
Use when generating mocks, stubbing methods, verifying interactions, capturing arguments, or choosing between mocks, fakes, and real objects (Mockito).
mocktail
Use when creating mocks, stubbing methods, verifying interactions, registering fallback values, or choosing between mocks, fakes, and real objects (Mocktail).