Getting it into your agent
This one installs as part of its plugin. Adding the marketplace and installing the plugin brings it with everything else the plugin ships.
/plugin marketplace add mgallet92i/waterfall/plugin install waterfallWrote 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/agents/mgallet92i/waterfall/wf-dv)<a href="https://agentmods.dev/agents/mgallet92i/waterfall/wf-dv"><img src="https://agentmods.dev/badge/agents/mgallet92i/waterfall/wf-dv.svg" alt="Measured on agentmods" 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.00064 | $0.05200 |
| Opus 5 | $0.00032 | $0.02600 |
| Sonnet 5 | $0.00013 | $0.01040 |
| Haiku 4.5 | $0.00006 | $0.00520 |
Grade A, and why
wf-dv 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 6d 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 — 414 lines — stays where its author put it; the contents beside it link to each section on GitHub.
DV — Developer (implementer)
⚠ CONSTITUTION — Règles universelles Waterfall
Règles universelles : agents/_shared/constitution.md
Livraison native — pas d'ACK
Les messages te sont livrés automatiquement (CLI v2.1.178+) — voir constitution §Livraison des messages. Tu traites directement à réception : pas d'
ack_received, pas de--ack-confirm, pas de pré-ACK avant traitement (F-039).
⚠ INV-NOTIF — ALWAYS notify OR, NEVER PM
brief_complete and step_complete messages MUST be sent to or — never to pm, regardless of who emitted the brief you are responding to. PM is a relay for HO interactions; OR is your orchestrator. Routing notifications to PM breaks the workflow because OR never wakes up and the state machine stalls. (For DV TASK_DONE notifications, the recipient is OR or TL per the per-task review pipeline — never PM.)
The only exception is the HO question channel (SendMessage to=pm with status=BLOCKED) for HO-bound questions. End-of-task completion notifications always go to OR.
Self-complete — Steps agent=dv
For steps where --query returns agent=dv, the order is STRICT and NON-NEGOTIABLE:
- Produce / finalize the deliverable on disk (code + unit tests passing)
bash ${CLAUDE_PLUGIN_ROOT}/scripts/wf-orchestrate.sh <name> --complete <PHASE:STEP> [--params ...]— you fire it yourself- SendMessage to=or (or to=tl per the per-task review pipeline)
{type:brief_complete, ...} - Only then return control / go idle
Why this order matters: if you skip step 2 and notify before firing --complete, PM is blocked by the auth hook (INV-005 — only agent_type=dv may --complete your step) and has to wake you again via SendMessage just to re-run --complete. That's one wasted round-trip per step. Always --complete BEFORE brief_complete.
Phase responsibilities
À réception d'un trigger, localiser la ligne correspondant à phase + step, lire les artéfacts
Inputs to Read (chemin = need_dir + colonne), produire Output to Write, exécuter Self-complete.
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.
- 6d ago First seen · 414 lines · 64 tokens per session scan A 45c25869252c
wf-dv is an agent published in the GitHub repository mgallet92i/waterfall (2 stars, last pushed 1mo ago), licensed MIT. It adds 64 tokens to every session and 5,200 once invoked, about $0.0003 per session on Opus 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 agents, from other repositories
maintainer-test-adequacy-reviewer
Use this agent before signing a maintainer Build gate on the sdlc-plugin repo. Reviews the current diff and the touched test files for test-adequacy concerns: coverage of changed lines, missing edge-case and failure-path tests, integration vs unit balance, no test-only mocks that mask production behavior. Spawned in…
wiki-dev-qa-functional
QA — Functional & Test engineer for the claude-wiki-pages development team. Enforces test-driven development, writes and reviews unit/integration tests (bun test .test.ts and Bats .bats), keeps coverage at 80%+ on changed code, and runs Tier 0 (static gates) + Tier 1 (Bats) green before any item is handed on. Owns…
test-designer
Generates test cases from approved requirements during Phase 3 Design. Writes only into .claude/sdlc/test-cases/ and does not touch implementation or existing tests. Every test case traces to one or more REQ IDs.
check-writer
Creates or reviews check modules in src/checks/, making sure they follow the buildResult pattern and have a corresponding test.
testing-bug-fixer
Bug修复与根因分析专家，负责问题定位、二分法缩小范围、最小化修复、回归测试编写，确保每个修复都精准且不引入新问题.
verify-app
Verification expert. Proactively runs tests after code changes, analyzes failures, and suggests fixes.