| name | recipe-cook |
| description | Author, run, and refine executable per-PR validation recipes for MetaMask work. Use when an agent needs to turn acceptance criteria, changed behavior, or reviewer requests into a portable recipe graph with concrete proof targets, project-native actions, and reviewable artifacts. Recipes may use recipe-wallet-control when available, but must not depend on it. |
| maturity | experimental |
Recipe Cook
recipe-cook turns PR claims into executable validation recipes: small graphs that map acceptance criteria to project-native actions, assertions, and reviewable artifacts.
Load only the files needed for the target repo:
- Recipe format:
references/recipe-v1.md
- Mobile-first recipe examples and composition patterns:
references/examples.md
- Evidence package shape:
references/evidence-package.md
- Runtime harness: use
/recipe-harness before claiming live Mobile or Extension recipe proof.
- Target-repo instructions are appended below when installed.
Mobile-First Quick Example
For Mobile, start with a small proof-target map, then compose existing flows or actions:
- PT-1: app is reachable on the intended simulator/device.
- PT-2: the target screen can be opened through the UI/navigation layer.
- PT-3: the changed state is asserted after a real wait condition.
- PT-4: reviewer-visible evidence is captured after the assertion.
Minimal Mobile smoke recipe shape:
{
"schema_version": 1,
"title": "Mobile smoke — wallet view is reachable",
"description": "Proves the debug Mobile app is reachable and can execute a harmless UI adapter action.",
"validate": {
"workflow": {
"pre_conditions": ["mm-4 or another intended simulator is booted", "debug app is installed"],
"entry": "status",
"nodes": {
"status": {
"action": "command",
"description": "PT-1: read app status through the Mobile agentic script",
"cmd": "bash scripts/perps/agentic/app-state.sh status",
"timeout_ms": 30000,
"stdout": "logs/status.json",
"next": "assert-status"
},
"assert-status": {
"action": "assert_json",
"description": "PT-1: status reports a device, platform, and current route",
"path": "logs/status.json",
"equals": { "platform": "ios" },
"next": "scroll"
},
"scroll": {
"action": "command",
"description": "PT-2: execute a harmless UI adapter scroll",
"cmd": "bash scripts/perps/agentic/app-state.sh scroll --offset 40",
"timeout_ms": 30000,
"stdout": "logs/scroll.json",
"next": "assert-scroll"
},
"assert-scroll": {
"action": "assert_json",
"description": "PT-2: scroll command reports ok=true",
"path": "logs/scroll.json",
"equals": { "ok": true },
"next": "index-artifacts"
},
"index-artifacts": {
"action": "artifact_index",
"description": "Index status and scroll proof logs",
"artifacts": ["logs/status.json", "logs/scroll.json"],
"next": "done"
},
"done": { "action": "end", "status": "pass" }
}
}
}
}
For product recipes, replace the smoke nodes with existing Mobile flows where possible: navigate first, wait for settled state, assert state/UI, then capture evidence. See references/examples.md for concrete Mobile composition patterns.
When to Use
Use this skill for PRs that need runtime proof, reproducible evidence, or a repeatable reviewer flow. Skip recipe authoring only when the change is static-only and ordinary lint/type/unit checks fully prove it.
Hard Rules
- Start from acceptance criteria or changed behavior, not from available tooling.
- Each proof target must have an action path, an assertion, and evidence when the result is reviewer-visible.
- User-visible UI claims need visual evidence. A recipe that only asserts state
or passes unit tests is incomplete for a visible banner, modal, button, route,
balance, form, or error-message claim unless the visual gap is explicitly
marked blocked.
- Runtime proof is not complete until the run emits
summary.json,
trace.json, and an artifact-manifest.json/evidence manifest that indexes
the screenshots, videos, logs, or state files used as proof.
- Prefer existing repo actions, fixtures, page objects, selectors, and test helpers.
- Recipes may use
/recipe-wallet-control where installed, but must remain understandable without that skill.
- Do not include SRPs, private keys, bearer tokens, production account dumps, or private user data.
- Do not mark a recipe proven unless it was run or the unrun gap is explicit.
Workflow
-
Extract proof targets
- Read the PR/task, changed files, issue, and acceptance criteria.
- Write 1-5 concrete proof targets: each should be observable, executable, and small enough to fail clearly.
- Mark any manual or environment-only target explicitly; do not hide untestable claims.
-
Choose the execution surface
- Prefer the project-native runner or existing scripts in the checkout.
- Use the installed repo overlay below before inventing actions.
- Use UI/mobile/browser actions only for user-facing behavior.
- Use command and JSON assertions for backend, static, or artifact-only behavior.
-
Author the recipe graph
- Use the v1 envelope in
references/recipe-v1.md.
- Keep setup/action/assert/teardown boundaries explicit.
- Give every node a stable
id, an action, and a human-readable description.
- Every non-terminal node must transition with
next, cases, or default.
- Every assertion should point back to a proof target.
- For
assert_exit_code, use "expected": 0 or another numeric expected code. Do not use "code".
- Add
timeout_ms to commands that can hang, such as focused Jest, build, simulator, or browser checks.
-
Run or dry-run what you can
- Execute non-destructive commands on the target device/session when available.
- For historical commits or fresh checkouts, run
/recipe-harness install and /recipe-harness verify before judging runner support.
- Treat dry-run as schema validation only; a recipe is not proven until the run emits
summary.json, trace.json, and the named artifacts.
- Runtime proof must record the harness adapter, source/version, verification status, and artifact paths.
- Save artifacts under
/tmp or a repo-ignored evidence directory unless the user asks to commit them.
- If a runner is missing, still produce the recipe plus the exact command or adapter work needed to run it.
-
Package evidence
- Follow
references/evidence-package.md.
- Include screenshots/videos/logs/reports only when they prove a named target.
-
Quality loop
- Use
/recipe-quality before calling the recipe done.
- Fix must-fix critique items, rerun if possible, then summarize remaining gaps honestly.
- If the critique says visual evidence is missing for a visible UI claim,
improve the recipe/evidence package or mark the proof target as blocked;
do not downgrade the claim to unit-test-only proof.
Output Format
When cooking, return:
Proof Targets — numbered claims and how each is proven.
Recipe — path plus important graph nodes, or the full JSON if short.
Run Command — exact command(s) used or needed.
Artifacts — paths and what each proves.
Quality Loop — critique verdict, improvement made, and rerun status.
Gaps / Follow-ups — only if something remains unrun, manual, flaky, or blocked.