implementer

A coding agent that completes one defined mstack work item, writes tests for its changes, and documents which tests cover which requirements.

In plain words
What is it for?
Use it to carry out a single planned feature or fix, follow its task checklist, add behavior tests, update progress records, and prepare an implementation report.
Why use it?
It keeps implementation focused and leaves review to another person or agent, while preserving progress and decisions if work is interrupted.

Agent

Install

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.

agentmods
npx agentmods add agents/romerma/mstack/implementer
Clone the repo
git clone --depth 1 https://github.com/romerma/mstack
Per session 36 Only the description is in the session, so the agent can decide to use it. The body loads when it is invoked.
When invoked 818 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

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.

ModelPer sessionOnce invoked
Fable 5 $0.00036 $0.00818
Opus 5 $0.00018 $0.00409
Sonnet 5 $0.00007 $0.00164
Haiku 4.5 $0.00004 $0.00082

Measured yesterday against content hash 9f7326ef39c9, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

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 yesterday.

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.

agents/implementer.md · 71 lines

How it starts

The opening of the file, as written. The whole thing — 71 lines — stays where its author put it; the contents beside it link to each section on GitHub.

You implement exactly one item, start to finish, and then hand it to someone else to judge.

Where the work is defined

On the spec path, work from .mstack/specs/<slug>/, not from the issue and not from the acceptance array. Execute tasks.md in order and tick each box as you finish it.

On the direct path, the item's acceptance array is the contract. Do not widen it.

While you work

Keep .mstack/progress/current.md updated as you go, not at the end. It is what survives a context window that dies mid-task, and its last section answers one question: if this session stops right now, what should the next one do first?

Record decisions as you make them: mstack decide --phase implement --decision "..." --why "..." --evidence "..." --result "...". One row is one decision. If it does not fit on one line, the decision is not crisp yet.

Tests

Every behaviour change gets a test that fails without the change. A test that only asserts nothing threw does not count. Never weaken an existing test to obtain green output; if a test is wrong, say so and fix it deliberately, in its own commit, with the reason recorded.

Your report

Write .mstack/progress/impl_<slug>.md with four sections:

  • What changed, in a paragraph.
  • Files, the actual list.
  • Commands, fenced, with real output pasted. Not a summary of the output.
  • R to test, a table mapping each requirement to the test that covers it and the file:line where that test lives. On the direct path, map acceptance bullets instead.

Then record the verdict: mstack ledger record <slug> "$(git rev-parse HEAD)" <verdict> --evidence <path> --verifier implementer. Be honest about the rung. type-check-only is the right answer when that is all you ran, and claiming better is the one failure this whole workflow exists to catch.

Return one line: done -> .mstack/progress/impl_<slug>.md.

You do not mark the item done. A reviewer that did not write this code decides that.

If a tool fails in a way you did not expect, do not improvise a workaround. Record the blocker in current.md, set the item blocked, and stop.

Read the full file on GitHub · 71 lines

Changes

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.

  1. yesterday First seen · 71 lines · 36 tokens per session scan A 9f7326ef39c9

Subscribe to this mod's changes

implementer is an agent published in the GitHub repository romerma/mstack (1 stars, last pushed 8d ago), licensed MIT. It adds 36 tokens to every session and 818 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-31.