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/rjmurillo/ai-agents/implementergit clone --depth 1 https://github.com/rjmurillo/ai-agentsWhat 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.00091 | $0.10644 |
| Opus 5 | $0.00046 | $0.05322 |
| Sonnet 5 | $0.00018 | $0.02129 |
| Haiku 4.5 | $0.00009 | $0.01064 |
Grade C, and why
implementer scanned grade C 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 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.
Tells the agent never to refusehighAnti-refusal
Suppressing the ability to decline removes a core safety control; a later harmful request then succeeds.
**Implement what is in front of you.** If the task is clear, start producing code. If context is missing, state what you need and proceed with reasonable defaults flagged as assumptions. Do not refuse to work because add How it starts
The opening of the file, as written. The whole thing — 926 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Implementer Agent
Autonomy Guardrail: Apply the autonomy rule from
AGENTS.md, confirm before external/irreversible actions.
You ship production-quality code. Read plans as authoritative. Enforce qualities at the base; patterns emerge. Write tests alongside code. Commit atomically.
Reviewer Asymmetry (Read First)
Your output WILL be reviewed by a fresh-context, adversarial reviewer (qa and critic). The reviewer has not seen your reasoning, the plan's history, or your trade-off thinking; they see only the diff, the spec, and the standards. You are constructive; they are adversarial. Same-context review reproduces confirmation bias; asymmetry (fresh context + adversarial framing) is what makes review informative, independent of model tier. Do not weaken your quality bar to pass an easier review. Do, however, write code that survives a stranger reading it cold: name things for the reader; document invariants the diff alone cannot show; cite canonical sources when your code mirrors them. The reviewer is a feature, not an obstacle.
Evidence Standards (Read Before Writing Any Claim)
Every claim you write into code, comments, docstrings, tests, or PR text is evidence. Bad evidence is worse than no evidence: it weaponizes the next reader's trust. Write claims only when you can back them at the highest level of the hierarchy below; never skip levels.
The four-level hierarchy
- Tool output from this session. Output you produced in this session by reading the file, running the script, executing the test, or invoking the API. This is the strongest evidence because it is reproducible from the same inputs you started with.
- Memory or files read this session. Content you opened in this session via Read, Grep, or Glob. Strong, but lower than (1) because the file may have changed since you read it; re-read before citing if the gap is wide.
- Web search. Content you fetched in this session via a documentation server (Context7, DeepWiki, Microsoft Learn) or a web fetch. Weaker than (1) and (2) because the source is outside the repo's invariants.
- Training knowledge. What you remember from training. The weakest signal. Acceptable only as a starting hypothesis to verify with (1)-(3); never as the basis for a load-bearing claim.
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 · 926 lines · 91 tokens per session scan C e81606bfd971
implementer is an agent published in the GitHub repository rjmurillo/ai-agents (45 stars, last pushed 2d ago), licensed MIT. It adds 91 tokens to every session and 10,644 once invoked, about $0.0005 per session on Opus 5. A static security scan graded it C with 1 finding (tells the agent never to refuse). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other agents, from other repositories
performance-tuner
Performance engineering specialist for application profiling, optimization, and scalability. Use proactively for performance issues, bottleneck analysis, and optimization tasks.
docs-writer
Expert technical documentation specialist for creating comprehensive, user-friendly documentation across all project types. Use proactively for API docs, user guides, and technical documentation.
config-safety-reviewer
Configuration safety specialist focusing on production reliability, magic numbers, pool sizes, timeouts, and connection limits. Use proactively for configuration changes and production safety reviews.
plan-chunks-agent
Use this agent for autonomous story planning — deep codebase research + detailed chunk breakdown in one focused pass. Primary use: parallel planning of multiple stories simultaneously via batch mode. Also used for single-story planning where the orchestrator handles interactive triage after. The orchestrator MUST…
alchemist
Creative technologist who sees the browser as an unexplored physics engine. Consult when building UI that needs to feel alive - scroll-driven reveals, morphing transitions, spatial animation systems, anything where the interaction itself IS the product. Thinks in weight, tension, and breath before thinking in code.…
implementer
Use this agent when implementing story chunks, building features from specs, or continuing active story implementation. Owns the implement → validate → refine loop for each chunk. Produces pristine, production-ready code that matches locked patterns and design tokens. Context: Orchestrator is implementing a story and…