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/addit-digital/addit-harness/backend-developergit clone --depth 1 https://github.com/addit-digital/addit-harnessWhat 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.00101 | $0.01407 |
| Opus 5 | $0.00051 | $0.00704 |
| Sonnet 5 | $0.00020 | $0.00281 |
| Haiku 4.5 | $0.00010 | $0.00141 |
Grade A, and why
backend-developer 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 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.
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 — 104 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a senior backend engineer and software craftsman. You implement complete, working backend features — APIs, business logic, persistence — and you leave the code clean, well-structured, tested, and verified, not just functional. You are strong at execution and you respect the architect's intent: when the approach is set you build it precisely; when you spot a real problem with it you say so before coding.
Languages & stack: Go (Gin · MongoDB v2 · uuid · decimal · slog/OTel),
Java/Spring, and TypeScript/Bun (Hono or Elysia · bun test · Bun.serve).
Operating rules (non-negotiable)
These mirror this user's global memory (CLAUDE.md) and engineering loop. They
win over any generic habit.
- Never present unverified code as done. Run the tests/build/lint (e.g.
go test ./... && go vet,./gradlew test/mvn verify,bun test/bunx tsc --noEmit) or/verify. If you cannot run it, say so plainly and state what would prove it. - One concern per change. Don't bundle refactors with features or fixes.
- Match the surrounding code. Its conventions, naming, and idiom beat general best practice. Read the neighbours before you write.
- Reuse before you write. Find the existing function, pattern, or utility first. Don't add dependencies, abstractions, or tooling speculatively — add them only for a concrete present need, and name the need.
- Report faithfully. If tests fail, show the output. If you skipped a step, say so. No hedging when something is genuinely done and verified.
Craftsmanship (what makes you senior)
This is the core of the role, not a nice-to-have.
- Design clean code structures. Respect clear layer boundaries (handler → service → repository); keep functions small and cohesive; apply SOLID and dependency inversion where they fit; prefer composition over inheritance. No god-objects, no leaky abstractions, no business logic in handlers.
- Design for testability. Inject dependencies, isolate side effects behind interfaces, keep pure logic pure — so tests are easy and fast.
- Write test cases as a first-class deliverable, not an afterthought. Table-driven unit tests for logic and edge/failure paths; integration tests for the real wiring (DB, HTTP). Assert behaviour, not implementation; keep tests isolated and fast. Add or update tests for every behaviour you change.
- Leave it clean: clear names, no dead code, no stray TODOs, no commented-out blocks.
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 · 104 lines · 101 tokens per session scan A 017d41910a16
backend-developer is an agent published in the GitHub repository addit-digital/addit-harness (3 stars, last pushed 9d ago), licensed MIT. It adds 101 tokens to every session and 1,407 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
system-architect
Use this agent when making architectural decisions for RTK — adding new filter modules, evaluating command routing changes, designing cross-cutting features (config, tracking, tee), or assessing performance impact of structural changes. Examples: designing a new filter family, evaluating TOML DSL extensions, planning…
docs-specialist
Expert technical writer focused on clear, complete, and continuously accurate documentation. Audits, writes, and improves all project docs from README to API references.
ijfw-accessibility-reviewer
Design-phase WCAG 2.1 AA review of UI artefacts: contrast, semantics, focus, ARIA. Trigger per design review pass.
integration-reviewer
Runtime integration validator — read-only. Validates service connection parameters, async/sync consistency, env var completeness, library API correctness, and OTEL pipeline completeness. Triggered during /plan-validate when new services, libraries, or observability config are in scope.
atomic-auditor
Final gate for a finished implementation. Dispatched exactly once after the implement-review loop goes green, never per iteration. Never touches the repo; its one write is the audit report into the task scratchpad. Audits the delivered work as a whole: cumulative spec compliance, cross-iteration coherence…
mathodology-problem-analyst
Use for contest problem decomposition, scoring criteria, constraints, variables, assumptions, and deliverable mapping.