recipes
0/5 steps
Tutorial V4 · 8–10 minutes

Cook a recipe from an acceptance criterion

Take one criterion off a ticket and end with a rerunnable proof of it. The recipe-cook skill drives this; you steer at the gates.

prerequisite: V3 skill maturity: experimental
V4

Video recording in progress

The flow

Cook classifies the request, then runs one checklist to completion.

1Classify dev · fix-bug · review-pr
2List and select a template discovery, then your pick
3Materialize one task an immutable checklist, one harness
4Execute the gates author, validate, run, mark

Template discovery runs through mm-harness execution-template, the same discovery contract as actions and recipes. Your team's library can supply its own templates.

Step 2 stops for you

For dev and fix-bug, Cook prints the compatible template IDs with a recommendation and then stops. It takes no further action until you reply with a number or an exact ID. This is the steering point: the flow is chosen by you, not inferred.

Follow along

Pick a small, real criterion — one observable behaviour, not a whole epic.

  1. Start Cook in your checkout

    In Claude or Cursor, invoke the skill with your task in plain language:

    /mms-recipe-cook Prove that a resting limit order can be repriced without losing its trigger

    In Codex, the same skill is addressed as $mms-recipe-cook. Product is auto-detected; you will not be asked which repo you are in.

  2. Choose the template

    Cook lists compatible IDs with one recommended. Reply with the number. It recommends an interactive template when human judgment is still needed and an autonomous one when it is not.

  3. Watch discovery set the boundary

    Before authoring anything, the vocabulary is fixed. Run it yourself to see what Cook is choosing from: 

    $ mm-harness actions --categories
$ mm-harness actions --action assert_orders

    An action outside this list cannot be written into a working recipe — validation rejects it before execution. That constraint is what makes the output trustworthy rather than plausible.

  4. Validate before executing

    Exit 5 means the recipe is wrong and nothing ran.

    $ mm-harness run ./my-recipe.json --plan
    ✓ [static] validate.schema: recipe document schema + action existence/platform vs the adapter manifest · [conditional] execute.nodes: would execute 4 recipe node(s)

  5. Run it, then try to break it

    $ mm-harness run ./my-recipe.json --artifacts-dir ./proof

    Then revert the change and run it again. A recipe you have watched fail for the right reason is one you can trust when it passes. If reverting the behaviour leaves it green, it is not proving what you think.

    Expect one failure-and-fix loop during authoring. Each error names its own next command; follow it rather than guessing. The falsifiability test lists the four shapes that pass for the wrong reasons.

Next: PR QA review → What makes a recipe good Back to the series