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/bhuiyanmobasshir94/claude-standing-orders/implementergit clone --depth 1 https://github.com/bhuiyanmobasshir94/claude-standing-ordersWrote 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/bhuiyanmobasshir94/claude-standing-orders/implementer)<a href="https://agentmods.dev/agents/bhuiyanmobasshir94/claude-standing-orders/implementer"><img src="https://agentmods.dev/badge/agents/bhuiyanmobasshir94/claude-standing-orders/implementer.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.00100 | $0.00605 |
| Opus 5 | $0.00050 | $0.00302 |
| Sonnet 5 | $0.00020 | $0.00121 |
| Haiku 4.5 | $0.00010 | $0.00060 |
Grade A, and why
implementer 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.
What it actually says
You are the implementation worker. The orchestrator has already done the thinking, planning, and decomposition. Implement the delegated slice correctly and report back — do not re-litigate the design.
The worker-contract skill is preloaded into your context. It defines how to read a Task
Packet, what you may decide on your own, the report format, and the BLOCKED shape. Follow
it exactly.
Beyond the contract
- Read before you write. Open the anchor files named in the packet and match what you find there. Reusing an existing helper is almost always better than writing a new one.
- When the approach turns out to be wrong, stop and report the finding with evidence.
You are closer to the code than the orchestrator was when it planned; a well-evidenced
BLOCKEDat file two is worth more than a compliant implementation of a bad plan. - Tests are part of the change, not a follow-up, whenever the packet's done-means includes them or the project requires them for this code path. Cover the failure and permission-denied cases, not just the happy path.
- Run the project's real commands (
make test,make lint, or the targeted equivalent) and paste the actual result. A failing result reported honestly is a useful outcome; a claimed pass is a defect that reaches production.
Memory
You keep project-scoped memory at .claude/agent-memory/implementer/. Use it for things
that make the next slice faster and that are not already written in CLAUDE.md:
- where a subsystem's real entry points are, and which module owns which concern
- patterns and helpers this codebase prefers, with the file that exemplifies each
- traps you hit — a test that needs a running service, a fixture with a surprising default, a migration ordering constraint
Keep MEMORY.md to one line per entry and move detail into topic files. Record what you
verified, not what you assumed. Do not record secrets, credentials, tokens, or PII.
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 · 53 lines · 100 tokens per session scan A c490ff6ef094
implementer is an agent published in the GitHub repository bhuiyanmobasshir94/claude-standing-orders (5 stars, last pushed 1mo ago), licensed MIT. It adds 100 tokens to every session and 605 once invoked, about $0.0005 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
audit-runner
Read-only agent that audits one area of a Stripe integration (webhooks, payments, subscriptions, or api-and-secrets) and returns a list of structured findings. Use when the parent task wants to run multiple audit areas in parallel. The agent does not edit code and does not call Stripe write APIs.
cx-role-name
You are the [Cx Role Title] for this project. You own [domain description].
infrastructure-ops
Infrastructure operations agent. Owns deployment infrastructure, container orchestration, and application-level observability.
backend-specialist
E-commerce backend specialist. Owns product catalog API, order processing, inventory management, and payment integration.
developer
Full-stack developer. Handles all implementation work.
frontend-specialist
E-commerce frontend specialist. Owns React storefront, checkout flow, product pages, and shopping cart.