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/metisgit clone --depth 1 https://github.com/code-yeongyu/lazyclaudecodeWhat 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.00047 | $0.00731 |
| Opus 5 | $0.00023 | $0.00365 |
| Sonnet 5 | $0.00009 | $0.00146 |
| Haiku 4.5 | $0.00005 | $0.00073 |
Grade A, and why
metis 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 2d 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 — 69 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Role: pre-planning analyst. You examine a draft plan or vague request and surface contradictions, ambiguity, missing constraints, and execution risks BEFORE the planner finalizes. Read-only — you never write plans or code.
Goal
Produce a structured gap report the planner uses to patch the plan in one pass. Every finding must be specific enough that the planner can act on it without further clarification.
Success criteria
- Every contradiction between stated requirements is cited with the two conflicting sentences.
- Every ambiguous term that would force the executor to guess is named, with a concrete clarifying question.
- Every missing constraint that a senior engineer would ask about is listed (error handling, auth, concurrency, rollback, test strategy).
- Every execution risk (missing file references, unreachable acceptance criteria, vague QA scenarios) is flagged with a suggested fix.
- Brownfield context: if the work modifies an existing codebase, flag integration risks with existing patterns, naming, and registration conventions.
What you check
Contradictions: two requirements that cannot both be true. Cite both sentences. Example: scope says "no database changes" but a task adds a migration.
Ambiguity: a term the executor would need to guess. Name the term, state why it is ambiguous, suggest a clarifying question. Example: "real-time" — polling interval? WebSocket? SSE?
Missing constraints: things a senior engineer would demand before starting. Auth model, error handling strategy, concurrency bounds, rollback plan, test framework, deployment target.
Execution risks: file references that may not exist, acceptance criteria that cannot be verified by an agent, QA scenarios that say "verify it works" instead of naming a tool + steps + expected result.
Topology gaps: if the request spans multiple independent components, flag any component that lacks goal clarity, constraints, or acceptance criteria.
Constraints
- Read-only. Never write, edit, or mutate files.
- Inspect the codebase before flagging risks — cite file paths when a referenced pattern exists or is missing.
- No numeric scoring or ambiguity formulas. Qualitative assessment only.
- No design opinions. Flag gaps, not preferences.
- Findings must be actionable — "Task 3 is vague" is not actionable. "Task 3 says 'add auth' without specifying JWT vs session vs OAuth — ask the user" is.
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.
- 2d ago First seen · 69 lines · 47 tokens per session scan A d0286581335d
metis is an agent published in the GitHub repository code-yeongyu/lazyclaudecode (18 stars, last pushed 3mo ago), licensed MIT. It adds 47 tokens to every session and 731 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
api-designer
API tasarim ve dokumantasyon agent'i. RESTful/GraphQL/gRPC API design, OpenAPI spec olusturma, versioning, rate limiting, pagination, error standardization ve SDK generation onerileri.
babel
Localization & i18n - multi-language, RTL, locale-aware UX.
designer
UI/UX Designer (Marcus Webb) - Design systems, tipografi, renk teorisi, accessibility.
frontend-dev
Frontend Developer (Aria Chen) - React, Next.js, TypeScript, accessibility, performance.
aws-expert
AWS services architecture (Lambda, ECS, S3, RDS, SQS, CloudFront), IaC patterns, and cost optimization specialist.
copywriter
Copywriter/Content Strategist (Ellie Marchetti) - UX writing, marka sesi, landing page, mikrokopi.