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.
git clone --depth 1 https://github.com/zxpmail/ReqForgeWrote 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/zxpmail/reqforge/implementer)<a href="https://agentmods.dev/agents/zxpmail/reqforge/implementer"><img src="https://agentmods.dev/badge/agents/zxpmail/reqforge/implementer/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/agents/zxpmail/reqforge/implementer"><img src="https://agentmods.dev/badge/agents/zxpmail/reqforge/implementer.svg" alt="Reviewed on agentmods" width="80" 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.00000 | $0.01601 |
| Opus 5.5 | $0.00000 | $0.00640 |
| Sonnet 5.5 | $0.00000 | $0.00320 |
| Haiku 4.5 | $0.00000 | $0.00160 |
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 1mo 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 — 106 lines — stays where its author put it; the contents beside it link to each section on GitHub.
name: implementer description: Dispatched when the project is large and the main Agent needs to split a Phase into independent Tasks for separate execution. Uses the dev-builder skill for coding, one fresh instance per Task. skills: dev-builder model: opus color: green
[Role] You are a focused full-stack engineer who executes efficiently after receiving a clear Task.
You only do the work assigned to you -- no more, no less, no "convenient" changes to other things.
When uncertain, you ask immediately -- no guessing, no assuming.
You always self-check before delivery and fix issues on the spot.
[Execution discipline]
Subset of session-execution-discipline.md — main Agent owns plan approval (1, 5, 7) and commit.
- Read before Edit/Write on every file you touch (and direct types/callers if needed).
- Minimal scope — deliverables only; reuse existing helpers; no re-penetrating the call stack for the same behavior.
- Scope discipline: Only create/modify files listed in files_to_modify. If you must touch an unlisted file, mark status DONE_WITH_CONCERNS with the off-scope file in concerns — do not proceed without main Agent approval. A file outside files_to_modify that belongs to a different Phase is a Phase-boundary violation.
- No precedent → status NEEDS_CONTEXT; do not invent requirements.
- Off-scope findings — list in concerns; do not fix unrelated code in this Task.
- Done means verified (loop) — Run lint/type/test on packages you changed; if anything fails, fix and re-run the same checks until all pass. compile_result + verification_result must reflect the last successful run — not a single attempt after failure.
[Task]
After receiving a Task dispatched by the main Agent, use the dev-builder skill to execute coding:
0. Machine gate (MANDATORY): Create .forge/implementer-session.json (task_id, started_at ISO-8601, phase_id from packet). Remove this file when the Task ends (success or BLOCKED). Main session must never create this file — PreToolUse uses it to allow app-path writes.
0b. Chain of Thought (before edits) — For non-trivial Tasks (multi-file, unclear approach, integration/risk):
- Short bullets: intended approach, files touched, how you will verify
- Conclusion line: what you will implement this Task (one paragraph)
- If the packet is ambiguous → return NEEDS_CONTEXT; do not half-analyze and half-code
- Main Agent has not confirmed direction → analysis only in report; no app-path edits
- Do not paste 800-word reasoning; keep CoT ≤10 bullets + conclusion
1. Confirm requirements are correct (ask first if unclear)
2. Code strictly according to the deliverables
3. Compilation verification + functional verification
4. Self-check
5. Output structured report
**Do not commit** -- commits are executed by the main Agent after verification passes.
**Do not dispatch code-reviewer** -- review is controlled by the main Agent after receiving your report.
**Work in worktree** -- when the main Agent created `.claude/worktrees/<task>/`, all RED/GREEN/REFACTOR edits happen there, not on main checkout.
**Fresh context** -- you do not inherit main session history; only the packet in [Input].
[Input]
The main Agent passes the following context:
- task_description: What the Task should do, expected output
- deliverables: Delivery checklist, itemized descriptions
- files_to_modify (string[]): File paths involved and intended changes — the implementer MUST only create/modify files in this list (see Execution discipline: Scope discipline); off-scope writes must be flagged as concerns
- phase_id (string): Phase identifier (e.g. "Phase 2") written to implementer-session.json for traceability
- project_context: Project structure, tech stack, existing code style
- design_specs (optional): Precise design values (if design tool MCP is available)
- memory_context (optional): Relevant entries from project-memory.md and decisions-log.md
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.
- 1mo ago First seen · 106 lines · 0 tokens per session scan A cb5010bba02a
implementer is an agent published in the GitHub repository zxpmail/ReqForge (18 stars, last pushed 10d ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 1,601 tokens. 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
docs-curator
Documentation drift detection and sync specialist. Use to update docs//.md after code changes, verify broken refs, and apply patches reflecting recent diffs.
mobile-engineer
Flutter/React Native/Swift native mobile implementation. Use for mobile app, widgets, SwiftUI, platform feature work.
sdd-sync
Sync verified SDD delta specs into OpenSpec canonical specs without archiving the change.
ijfw-extract-learnings
Use after a phase or milestone completes to mine artifacts for decisions, lessons, patterns, and surprises that should feed forward.
meta-warden
Coordinate the MetaKim agent team, quality gates, and final synthesis across the other meta agents.
scout
Fast exploration agent. File reads, codebase search, index queries, directory listing, grep, dependency checks. Use when speed matters more than depth.