The stack behind a recipe

How the pieces fit together

The recipe is the unit of trust; the rest of the stack runs it. Four moving parts, two of which people routinely confuse. What each layer is, where it lives, which workflow you are in, and the mistakes that cost newcomers their first afternoon.

The one-paragraph model

A recipe proves a task with actions. Recipes are JSON graphs of typed actions; mm-harness executes them against a real app and produces an evidence bundle a reviewer can trust. Skills teach an agent a workflow — author a recipe, review a PR, validate a release — and are the layer you work through; they call the harness, which runs the recipe. Recipe libraries hold each team's recipes and domain actions. Compose in that order, against the product repo under test.

The layers

Click a layer to see what it is responsible for and when you touch it.

The CLI: launches the app, exposes the action vocabulary, executes recipe graphs against a real build, writes the evidence. The only layer everyone needs, and the only one installed globally:

$ npm i -g @deeeed/metamask-harness@latest

It owns MetaMask runtime control and the domain capabilities; the generic graph engine and the evidence schemas underneath it are separate packages it depends on.

A team-owned repo of reusable recipes plus the domain actions they need. The harness ships a bundled library so a fresh install can prove something immediately; your team's library is where the recipes that matter to your work live.

Libraries must be declared, or the harness only sees the bundled set:

$ export RECIPE_LIBRARY_PATH="perps=$HOME/dev/my-recipe-library"
$ mm-harness run <recipe> --library perps=$HOME/dev/my-recipe-library

Each library carries its own setup notes — read those before running anything domain-specific.

The spec underneath

mm-harness implements farmslot, a versioned specification for agentic proof work. The CLI is one implementation of it, not the thing itself.

1 The specification recipes, action manifests, observations and traces, evidence, handoff

2 mm-harness implements it for MetaMask products

3 Skills drive it the workflows an agent follows

Schemas are published and versioned. Every recipe carries the URL it validates against:

"$schema": "https://farmslot.io/schemas/recipe-v1.schema.json"

Action manifests carry action-manifest-v1; evidence records its own schemaVersion and runner_protocol_version. Versioning is what keeps a bundle readable by tooling written after it was produced.

Why the spec is the scaling mechanism

The recipe you run from the CLI is the same artifact a control plane dispatches to a worker, monitors, and gates — dispatch, worker, self-review, human gate, publication, each step speaking these contracts. Evidence returns in the same shape either way, so a fleet result is reviewable by whoever wrote the recipe. Parity is structural: one spec, both sides.

That is what makes the trust layer scale. A proof written once becomes a permanent guard: it is replayed by whoever changes that code next, it stays readable as evidence no matter who or what ran it, and the bug it was written for cannot quietly return. Review does not get weaker as volume grows.

The seam shows in the CLI's own help — the flags a control plane supplies:

managed trust boundary (not needed for normal runs; Farmslot supplies it): --source-trust, --source-kind, --source-name, --source-digest, --approve-plan (binds approval to the exact reviewed plan)

Approve a plan and only that plan runs — which is what keeps the gate a gate.

What you actually need

The farmslot control plane is experimental and sole-maintained. Nothing this site teaches requires it — the harness, recipes, and skills are complete on their own, and the CLI says as much: those flags are "not needed for normal runs". The specification is what you adopt; the control plane is one consumer of it.

The improvement loop

A recipe guards the regression it was written for. This is how a team catches the ones nobody has written down yet — each run leaving the next one better informed.

Learnings are written, not collected. The checklist an agent follows carries a step instructing it to write what it learned as human-readable markdown, bundled beside the execution plan and the evidence. A run ends with prose — what was hard, what surprised it, what the next run should know — sitting next to the proof. A deliverable, not telemetry: nobody mines traces for insight; the agent is asked and answers.

The chain

1 A checklist step asks for learnings part of the execution plan

2 The run writes learnings.md beside its evidence prose, in the run artifacts

3 Curation promotes the durable ones a human decides what generalises

4 They become team knowledge in the library, beside the recipes

5 The next run loads it before acting discovery, not recall

Step 3 is a person on purpose: a run produces plenty of true-but-local detail, and promoting all of it buries what matters — the same judgement as deciding what belongs in a code comment.

Where learnings collect

Scrubbed packages from approved runs land in MetaMask/experimental-distributed-learnings, a private append-only inbox — the same repository as experimental-agentic-learnings, which was its earlier name and still redirects. Capture records the observation, review later decides whether it warrants a proposal, and proposals go to whichever repo owns the affected layer. Sharing is opt-in: without a local learning.config.json a run stages locally and publishes nothing. Packages are date-partitioned and the indexes are scaffolded, but only one day of runs has landed so far — collection is beginning, so treat it as the destination rather than a corpus to read today.

What works today

Mechanism	Its part in the loop
The evidence bundle	Produces the raw material. `diagnostics.json` in particular is where side findings land — application warnings and errors captured during the run, kept out of the verdict precisely so they survive as observations rather than being flattened into pass or fail.
Team recipe libraries	The place shared understanding accumulates. A recipe that encodes "get to a clean market first" is a piece of team knowledge, already reusable by everyone who declares the library.
`mm-harness recipe-quality`	Turns a review's verdicts into a quality artifact, so an assessment of a proof is itself a durable record rather than a comment that scrolls away.
`mm-harness execution-template`	Discovers, validates, and materialises shared agent checklists — a curated procedure written once and picked up by everyone, which is the loop working at the level of process.
Skills	The same idea for workflows. A skill is a procedure someone got right, packaged so nobody has to rediscover it.

Where this is heading

The gap is the middle of the loop: recipes and actions have a home in a team library; the sharper things a run teaches you do not yet. Worth capturing:

Gotchas — the non-obvious precondition that cost someone an afternoon, written down once.
Screen maps — how a surface is actually reached and identified in the current build, so the next author is not re-deriving it.
Flakes — the step known to be intermittent, with what is known about when and why, so an author can distinguish a real failure from a familiar one.

The intended shape is the one proven everywhere else here: discovery rather than recall. Just as you ask the checkout what actions exist, you would ask what is already known about a surface before authoring against it — a knowledge surface alongside actions and run --list, resolving the way libraries already do, layered most-specific-wins: yours, your team's, the workflow's, then defaults shipping with the harness release so tool facts cannot drift out of date in a document nobody re-reads.

Entries stay small and curated: a short index of what exists and when to load it, topic files under a size cap, each entry carrying a stable id and the same symptom → cause → what to do shape the error messages use. Promotion happens through an ordinary reviewed pull request, so a human is in the loop by construction.

Being straight about status

Not shipping yet. There is no knowledge command today, which is why you will not find one in a copyable block on this page. Meanwhile the useful part is unblocked: keep what your runs teach you in the library repo beside the recipes. Tooling makes it discoverable later; writing it down is what makes it exist.

The skills teach the workflow; the knowledge teaches the product. Runs produce learnings, curation promotes them, discovery serves them to every run after.

Where everything lives

What	Is	You need it when
`@deeeed/metamask-harness` the `mm-harness` CLI, on npm	The execution engine and evidence producer: `doctor`, `launch`, `actions`, `call`, `run`, `last`.	Always. Install and update with `npm i -g @deeeed/metamask-harness@latest`.
`Consensys/skills` internal repo	Agentic skills — recipe authoring, PR QA review, release validation. Installed into a checkout via that repo's tooling.	When you want an agent to follow a proven workflow instead of improvising one.
Team recipe libraries e.g. the perps and money-movement libraries	Team-owned recipes, domain actions, and domain knowledge. Declared with `RECIPE_LIBRARY_PATH` or `--library`.	When running or authoring anything domain-specific. V3 walks the setup with the perps library as the worked example.
Product repos extension · mobile · core	The thing under test. The harness runs against a real checkout and a real build.	Always — there is nothing to prove without one.

The three workflows — pick one, do not blend them

Most confusion here is someone doing two at once. They need different setup and fail differently.

1 · Run an existing recipe

No skills needed. This is the majority of daily use.

$ mm-harness update
$ cd <product checkout>
$ export RECIPE_LIBRARY_PATH=<name=path>
$ mm-harness doctor
$ mm-harness launch
$ mm-harness run <recipe> \
    --artifacts-dir ./out

Evidence lands in the artifacts dir. That is the whole workflow.

2 · Author a recipe

For a specific acceptance criterion. Skills earn their keep here.

Install the recipe-authoring skill. It discovers the vocabulary with mm-harness actions — the discovered list is law, action names are never invented — composes the graph, validates it with run --plan, then runs it for real.

Expect one honest failure-and-fix loop. That is the error messages doing their job.

3 · Review a PR / validate a release

Requires the QA skills.

Give the skill one PR URL. It extracts the acceptance criteria verbatim — missing ones become a hygiene finding, never an invented criterion — waits for you to confirm or edit the table, runs the proof on a real device, and produces a per-criterion verdict with evidence paths.

A criterion the surface genuinely cannot prove is reported as needing a human, not quietly passed.

Why "do not blend them" is a real instruction

Running a recipe needs no skills; reviewing a PR does. Install everything and ask an agent to "just handle it" and you get an agent choosing between procedures with no basis to pick. Name the workflow you are in.

The five mistakes every newcomer makes

Asking the agent to figure it all out from one sentence. The skills are the figured-out part. Name the workflow you want; do not make the agent guess which of the three you are in.
A stale harness. This one costs the most afternoons. The CLI ships often and recipes assume current behaviour. Run mm-harness update before you debug anything that "used to work".
Not declaring the library. Without RECIPE_LIBRARY_PATH (or --library) the harness only sees bundled recipes — so your team's recipe appears not to exist, and the error is telling the literal truth.
Skipping doctor. It tells you exactly what is missing and the exact command that fixes it. Every error in this stack carries a Next: action. Read them — that is the whole design.
Blending the workflows. See above. Mixing "run a recipe" with "review a PR" confuses the agent and produces work you then have to check by hand.

Which repo is which

The layers above are the design. The Ecosystem map is the concrete version: the six repositories and packages behind a run, each with its URL, and which way the dependencies point.

See the repo map → Do the walkthrough Read an evidence bundle