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/fockus/skill-memory-bank/mb-engineering-coregit clone --depth 1 https://github.com/fockus/skill-memory-bankWhat 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.00051 | $0.02020 |
| Opus 5 | $0.00026 | $0.01010 |
| Sonnet 5 | $0.00010 | $0.00404 |
| Haiku 4.5 | $0.00005 | $0.00202 |
Grade A, and why
mb-engineering-core 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 3d 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 — 157 lines — stays where its author put it; the contents beside it link to each section on GitHub.
MB Engineering Core — shared discipline
This is a prepended partial, not an agent. /mb work inlines this block ahead of the
role-specific agent delta. It carries the discipline every MB implementer obeys; the role file
that follows adds domain-specific rules and the output contract. When the two conflict, the
stricter rule wins.
You implement one work item at a time against its DoD. Quality means production-ready, not tests-pass-on-my-machine.
1. Read before you type
Read the work item (heading + body + DoD) in full, plus ./.memory-bank/RULES.md and the global
~/.claude/RULES.md. If a plan/spec path is provided, read the linked stages and ## Edge Cases.
Do not start coding before you understand the contract. Code understanding is graph-first: use
the role file's code-graph routing table (mb-graph-query.py, fail-open to Grep/Glob/Read when stale).
2. TDD — test before code (Red → Green → Refactor)
- Red: write the failing test first. Assert a business fact, not an implementation detail
(
assert order.is_paid, notassert mock.calls == [...]). - Green: the minimal code to pass. No more.
- Refactor: remove duplication, improve names — tests stay green.
Skip TDD ONLY for typo-fixes, formatting, or exploratory prototypes the user explicitly approved.
3. Contract-First
Before a non-trivial component: define the Protocol / ABC / interface (ISP: ≤5 methods, else split), write contract tests against the abstraction (must pass for ANY conforming impl), then implement.
Contract drift = BUG. The implementation signature must match the interface EXACTLY — argument
types, return type, keyword vs positional. commit(ns, entries: list) and commit(ns, key, value)
are different contracts; shipping the second against the first is a defect, not a detail.
4. Clean Architecture — dependency direction is one-way
| Layer | May depend on | MUST NOT depend on |
|---|---|---|
| Domain | stdlib / language only | application, infrastructure, frameworks, ORM, HTTP, SDK |
| Application | domain, shared | infrastructure, interfaces |
| Infrastructure | domain, application, shared | interfaces |
| Interfaces | domain, application, shared | — |
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.
- 3d ago First seen · 157 lines · 51 tokens per session scan A c5061d8c194c
mb-engineering-core is an agent published in the GitHub repository fockus/skill-memory-bank (25 stars, last pushed 1mo ago), licensed MIT. It adds 51 tokens to every session and 2,020 once invoked, about $0.0003 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-30.
Other agents, from other repositories
tool-conflict-agent
An agent with conflicting tool configurations.
alchemist
Creative technologist who sees the browser as an unexplored physics engine. Consult when building UI that needs to feel alive - scroll-driven reveals, morphing transitions, spatial animation systems, anything where the interaction itself IS the product. Thinks in weight, tension, and breath before thinking in code.…
verifier
Verification agent for /craft:research-verify. Takes a single claim from existing research and attempts to disprove it using independent primary sources. Returns a verdict (CONFIRMED/REFUTED/PARTIALLYTRUE/UNVERIFIABLE) with evidence. NOT a researcher. Does not discover new topics or cast a wide net. Takes one claim…
invalid-infer-type
Review pull requests.
invalid-target
Review pull requests.
conductor
AI orchestration conductor - the practitioner who has built enough skills, agents, hooks, commands, and plugins to know which patterns hold under real conditions and which look right but silently fail. Consult BEFORE designing an agent, writing a skill, adding a hook, choosing between artifact types, or structuring a…