@mvpscale/mm3

In your agent, add the marketplace and install the plugin:

/plugin marketplace add mvp-scale/mm3
/plugin install mm3@mvp-scale

Or from a terminal:

npm install -g @mvpscale/mm3
mm3 init --agents

Done. Each agent's exact command, and what we tested · checklist and ledger

Bring your own key and base URL. No key? MM3 still runs, on labelled samples.

export TYPESAFE_API_KEY=...
export TYPESAFE_BASE_URL=https://your-typesafe.example

Using the plugin? Keep the key in its secure settings instead (Claude Code: /plugin configure mm3@mvp-scale). Then run your agent: it writes the request YAML in seconds. Needs Node 22.13+, or the standalone build. More: the config guide.

See it run

The challenge: you host n8n yourself and want it to run faster. You ask your agent where to start. It narrows the question to one place, the node loader's cleanup in directory-loader.ts, and asks MM3 twelve questions about it in one call: nine yes/no, two decisions and the goal itself.

The request the agent wrote (45 lines): The response, real output · jev-1.13.0 · api.typesafe.ai · 321 ms · ~$0.000063:

• Every concern is written so that "no" is healthy: a pass: no answer clears the bar at 0.30 or below.
• Goal: pass (0.79). Yes, this cleanup could be faster.
• Availability: fail. At 0.88, the realpathSync() calls on line 606 block the event loop.
• Design: fail on all three: a rescan on every unloadAll() call (0.78), a try-catch that silently skips errors (0.90), and caching would help (0.84).
• Design-risk: unsure. None of 0.40, 0.46, 0.64 lands clearly either way.
• Decisions: measure first passes (0.89); severity is unsure (low, 0.56).
• Next: the concerns disagree, so consensus is SPLIT, escalate is true, and next: points at a drill into availability. The mdl: line lists what the ledger recorded about why the agent asked, so later runs on this code start from it.

Why MM3

An agent can ask a fast classifier a yes/no about your code, but on its own that answer is untraceable and never reused. MM3 asks the same way every time, scores the answer and keeps it, so every check adds to what you know about your codebase.

Three angles, three kinds of knowledge. Every concern is asked three ways, so no decision rests on one look. Every request keeps what you asked, the scored verdict and the problem you were working on. Know what you know, judge fairly, prove it.

The name is MAK³ (make) plus MDL³ (model), each across Know, Judge and Prove. It started as Sidewise; we hope you like the new name.

MAK³ uses what is proven. Know what's been done here before you act, judge one claim, prove the change. MDL³ learns what is missing. In code you don't know yet: take a census, follow the flag, prove the design before anyone builds it. view knows the past, scan the present, loop the future. Any order; every run feeds the next.

The ledger is our favorite part. One append-only JSONL file. The runs you'd make anyway become a heat map at 10, a reference architecture at 20, a knowledge graph at 50. And mdl: is open: keep the stock fields, add your own, free, and your agent paints any of it back from the log or the SQLite index.

mdl:
  # stock
  why: find                    # validate · find · debug
  area: [build, hosting]       # where in the stack
  stage: operate               # design … operate
  problem: n8n startup scans node_modules with sync FS calls     # one line, your words
  uses:                        # C4 chains
    - person:self-hoster -> system:n8n -> container:n8n-main
    - container:n8n-main -> component:core/nodes-loader -> code:unloadAll
  blast: container             # how far a failure reaches
  # yours: any key, any lens
  hypothesis: caching symlink roots cuts cold start by a third   # developer
  user-feels: first workflow after a restart is slow             # product
  cost-driver: every pod restart pays the full scan              # business
  pager-risk: none, slow not down                                # on-call
  tags: ["#perf", "#cold-start", "@platform-team"]               # common dev tags: #topic, @owner
  refs: [BUG-1042, "test:startup-bench failed"]                  # bugs, test results, anything to link

Once a field settles over a few runs, mm3 report fields --accept tags promotes it: every tag becomes a node in the knowledge graph, tied to the runs that carried it. Same questions on unchanged code come back from the ledger: no call, no cost. mm3 report shows where your agents keep going wrong, and a budget cap that only you raise stops runaway spend.

Architecture

That's all of it: one engine on your machine, one folder in your project, one call out. Simple on purpose, built to grow.

Patterns

The same six verbs, used five ways. You know the fundamentals; this is how it multiplies your game, from your first check to a loop that runs itself. Each level has a recipe for every verb.

Open the pattern playbook. The multipliers are a mental model, not a benchmark. A recorded journey down each level is coming: stay tuned.

Journeys

Each journey asks one question: can a smaller model, with MM3, learn more about a real codebase for less? One agent, a $1 cap that covers everything, the same three beats (Know, Judge, Prove). Every run is on file in mm3-journeys, so you can rerun it and compare.

Journey 1: WordPress

The hook: take WordPress 7.1.2 as it ships and teach it to render a page differently for each reader, as a plugin, core untouched. The recap: one agent mapped WordPress, checked its plan before writing code, then committed a small plugin and proved what held. MM3 cost about a tenth of a cent. The agent cost about $0.98 at today's list prices, so the whole journey came in under the $1 cap.

How to read it. A gap is a requirement MM3 found, not a failure: gap is fail, open is unsure, met is pass. The agent's figures are counted from its session's token usage and priced at list; the score is against our own answer key. Every verdict came from reading code, not running WordPress. It missed WordPress's Block Bindings API, and replay can't yet compare against a file that didn't exist before (it's beta).

What we prompted (the goal, verbatim; the beats and budget follow in the full brief):

Goal: a page in WordPress renders differently depending on a simple persona of the current user, built from what WordPress can already see about them (what they read, what they like, what they adjusted). It only has to prove the page can change by persona; how accurate the persona is doesn't matter. Build it as a plugin under src/wp-content/plugins/; don't edit WordPress core or the bundled themes.

All of it is public: the brief, the notes for each beat, the diff, the score against our answer key and the full ledger for each of the three runs: run 1, bare brief, run 2, plugin guidance, run 3, each beat spelled out.

[!IMPORTANT] Lessons learned. The prompt decides whether your agent uses MM3 as a map or as a spot check: 2 runs on a bare brief, 14 when each beat was spelled out.

Corrective action. If you want the map, spell the steps out in your agent's brief; the run 3 brief linked above is a starting point. MM3's own guidance stays short on purpose, because one class call is often the whole job. mm3 init --agents adds a pointer to MM3's command cards to AGENTS.md and points CLAUDE.md at it.

Run it

Let your agent drive. mm3 agent prints every command and rule in one dense card built for agents, and mm3 agent <verb> gives one verb's rules with good and bad examples. Claude agents read it and run the commands just fine, down to Haiku: it drove both of our stories end to end.

For humans, mm3 help is the same contract in plain words, and mm3 template <verb> prints a filled-in request with its rules as comments. Four jobs to start with:

• Check a change before you merge it. One class call, three angles per concern, a verdict for each. Start with mm3 template class.
• Prove a fix actually worked. replay re-asks a past run's own questions across two commits, so you check the fix without re-checking everything. Start with mm3 template replay.
• Find where a problem lives. scan sweeps a folder and ranks the files that most need a look. Start with mm3 template scan.
• Check a design before any code exists. loop puts a plan through the same checklist before anyone writes it. Start with mm3 template loop.

Every line below runs in order in a fresh project:

# mm3-quickstart
mm3 template class > review.yaml
mm3 class review.yaml
mm3 view src
mm3 report
mm3 outcome MM3-0001 held --by you
mm3 budget

Add --dry-run to any request to validate it and count its questions without a call. With no key set, MM3 falls back to a built-in sample provider so these lines still run; its answers are canned and labelled, never evidence.

Limits and alternatives

• Advice, not action: it gives the odds, you make the call. Delete, deploy, drop and pay stay human.
• A pass is a probability: a calibrated 0.9 is wrong one time in ten. unsure is a real answer, and mm3 outcome shows which verdicts held.
• Run linters, scanners and tests first: they're free and exact. MM3 takes the questions they can't ask, like "does this handler check the caller?"
• First principles still apply: map your architecture first. A few cheap checks name the layers (tag requests with mdl.uses) and mm3 report graph draws them. Every later question then lands in a known place, and reading it back is free.
• Use a full review for open questions. A model that reads the whole codebase answers anything. MM3 answers yes/no.
• Beta: works well in our own use and on an intentionally vulnerable app (OWASP NodeGoat). Formal benchmarks are coming.

Docs and contributing

• The contract: every claim the answer format makes
• Evidence for each claim and where the numbers come from
• The agent skill, and mm3 agent / mm3 help in your terminal
• Contributing: see AGENTS.md for commands, test tiers and rules. Open pull requests against the nightly branch.

License

Apache-2.0 · Contributing · Issues