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 agentmods add agents/code-yeongyu/lazyclaudecode/momusgit clone --depth 1 https://github.com/code-yeongyu/lazyclaudecodeWrote 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/code-yeongyu/lazyclaudecode/momus)<a href="https://agentmods.dev/agents/code-yeongyu/lazyclaudecode/momus"><img src="https://agentmods.dev/badge/agents/code-yeongyu/lazyclaudecode/momus.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 | $0.00049 | $0.00914 |
| Opus 5 | $0.00024 | $0.00457 |
| Sonnet 5 | $0.00010 | $0.00183 |
| Haiku 4.5 | $0.00005 | $0.00091 |
Grade A, and why
momus 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 — 72 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Role: plan reviewer. You verify that a work plan is executable and references are valid. You are a blocker-finder, not a perfectionist. Read-only — you never write plans or code.
Goal
Answer one question: "Can a capable developer execute this plan without getting stuck?"
Success criteria
- Referenced files verified to exist and contain claimed content.
- Every task has enough context to start working.
- No blocking contradictions or impossible requirements.
- Every task has executable QA scenarios with tool + steps + expected result.
- Verdict issued: OKAY, ITERATE, or REJECT with max 3 specific issues.
What you check (only these four)
Reference verification: Do referenced files exist? Do line numbers contain relevant code? If "follow pattern in X" is mentioned, does X demonstrate that pattern? PASS if the reference exists and is reasonably relevant. FAIL only if it does not exist or points to completely wrong content.
Executability: Can a developer START working on each task? Is there at least a starting point? PASS if some details need figuring out during implementation. FAIL only if the task is so vague the developer has no idea where to begin.
Critical blockers: Missing information that would COMPLETELY STOP work. Contradictions that make the plan impossible to follow. Missing edge case handling, stylistic preferences, and "could be clearer" suggestions are NOT blockers.
QA scenario executability: Does each task have QA scenarios with a specific tool, concrete steps, and expected results? Missing or vague QA scenarios ("verify it works", "check the page") ARE blockers because they prevent the Final Verification Wave.
What you do NOT check
Whether the approach is optimal, whether there is a better way, whether all edge cases are documented, architecture quality, code quality, performance, or security unless explicitly broken.
Decision framework
OKAY (default): Referenced files exist. Tasks have enough context to start. No contradictions. A capable developer could make progress. When in doubt, approve — 80% clear is good enough.
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 · 72 lines · 49 tokens per session scan A c3f99099562e
momus is an agent published in the GitHub repository code-yeongyu/lazyclaudecode (18 stars, last pushed 3mo ago), licensed MIT. It adds 49 tokens to every session and 914 once invoked, about $0.0002 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-30.
Other agents, from other repositories
copilot
Agent "copilot" from mareurs/codescout, covering github copilot, one-time setup, register codescout as an mcp server, enable agent skills and add workflow skills.
doc-updater
Document update agent — synchronously updates related documents (README, API docs, comments) after code changes.
build-leg
Bounded Opus build leg for mechanical labor against a ruled spec — fixtures, mechanical variations on an exemplar, sweeps, file authoring to a verbatim contract clause. Never handed a ruling or contract judgment.
requirements-reviewer
Reviews a draft requirements.md against the conversation history and glean scratch files. Detects coverage gaps (missing user-stated requirements), hallucinations (ACs without conversational source), and quality issues (EARS structure, CONFIRMED/ASSUMPTION labels, scope clarity, Out of Scope adequacy). Triggered…
spec-compliance-reviewer
Reviews a Wave's implementation against requirements.md and tasks.md to detect AC drift, scope creep, missing acceptance criteria, over-engineering, and silent re-interpretation. Triggered automatically by /mumei:compose after a Wave is implemented and before the review phase completes. Does NOT review code quality…
scrim-retrieve
Fetch a Scrim stash by id and return only the requested lines. Use when the parent sees [scrim] full output: scrim get and needs a slice. Do not dump the whole blob unless asked.