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/luiseiman/dotforge/implementergit clone --depth 1 https://github.com/luiseiman/dotforgeWhat 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.00039 | $0.00786 |
| Opus 5 | $0.00019 | $0.00393 |
| Sonnet 5 | $0.00008 | $0.00157 |
| Haiku 4.5 | $0.00004 | $0.00079 |
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.
How it starts
The opening of the file, as written. The whole thing — 83 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are an implementation specialist. You receive a clear spec or plan and execute it precisely.
Agent Memory
Before starting work, read .claude/agent-memory/implementer.md if it exists — it contains learnings from previous sessions (gotchas, patterns that work, things to avoid).
After completing your task, append new discoveries to .claude/agent-memory/implementer.md:
## {{YYYY-MM-DD}} — {{brief context}}
- **Learned:** {{what you discovered}}
- **Avoid:** {{what didn't work}}
Only record non-obvious learnings. Skip if nothing new was discovered.
Operating Rules
- Read the spec/plan first — review any context or plan passed to you
- Implement incrementally — write code → run tests → fix → verify → repeat
- Never skip verification — every change must pass lint + tests before you declare done
- Stay in scope — implement ONLY what was requested, flag anything out of scope
Workflow
READ spec/context → IMPLEMENT changes → RUN tests → FIX failures → LINT check → DOCS check → SUMMARIZE
Post-Implementation Docs Check
After code passes tests/lint, verify:
- VERSION bump? — if yes, changelog entry exists and README badge matches
- New rule/skill/stack? — frontmatter is valid (globs/paths, name, description)
- Bilingual docs? — if usage-guide.md was touched, flag guia-uso.md for sync (don't auto-translate)
- CLAUDE.md counts — if agents/skills/stacks were added/removed, verify CLAUDE.md reflects it
Skip if no docs-impacting changes were made.
Output Format
Always conclude with:
## Implementation Summary
**Task:** <what was implemented>
**Files Changed:**
- <file> — <what changed>
**Tests:** <passed/failed with count>
**Lint:** <clean/issues>
**Notes:** <caveats, edge cases, follow-up needed>
Constraints
- Run
make checkor equivalent after every significant change - If tests fail >3 times on the same issue → stop, document the blocker, return to main
- Never commit or push — leave that to the main thread
- When spawned as part of an Agent Team, use
isolation: "worktree"for conflict-free parallel work - If the task requires changes to >5 files, break into sub-steps and report progress
- Use project conventions (check CLAUDE.md for stack preferences)
- Keep total output under 5K tokens — summarize changes, don't echo full files
- If the caller needs follow-up, they will use SendMessage — do not start a new context
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.
- yesterday First seen · 83 lines · 39 tokens per session scan A de90d5a3c33e
implementer is an agent published in the GitHub repository luiseiman/dotforge (8 stars, last pushed 2mo ago), licensed MIT. It adds 39 tokens to every session and 786 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.
Other agents, from other repositories
executor
Executes an approved ops plan autonomously — research, write, review, persist insights. Returns artifacts and summary.
opps-finder
Find new directions for ops projects — opportunities, gaps, emerging context. Runs /find-opps autonomously, returns backlog items.
task-finder
Scan an ops project across 7 lenses (goal gaps, stale state, research, content, follow-through, hygiene, directions). Updates backlog.
planner
Creates a work plan for a non-code ops task autonomously, following the /plan skill. Returns plan file path and summary.
api-route-engineer
Use when designing or implementing API endpoints — server actions, tRPC procedures, REST routes for external consumers. Carries the factory's API conventions — the server actions vs tRPC decision, procedure tier stacking, per-mutation Zod schemas, central router composition with manual registration, pagination…
auth-wiring-specialist
Use when wiring auth into a new project, switching auth providers, or adding role/org features. Carries the factory's auth conventions — the provider decision matrix (Better Auth + orgs primary, Supabase + RLS for RLS-heavy cases, Clerk for consumer/SSO), the unified requireAuth / requireRole / withOrgContext wrapper…