Recipe-Based Testing · TRIF

Tests your agent can actually run.

TRIF captures an app's testing knowledge once, as portable human-readable recipes — so any AI agent, engine, or human runs a test from a tiny slice of context, grades it against an explicit oracle, and tells a real bug apart from a stale assumption. Open format. Zero-dependency kit. Runs from your CLI or straight from an agent over MCP.

npm i -g test-harness-kit  ·  Apache-2.0 · CC-BY-4.0 spec · Node ≥ 18
zsh — a live run against Wikipedia
$ npx test-harness-kit run wikipedia.trif TC-01 TC-08 --adapter playwright TC-01 PASS/clean 2082ms [intent:playwright] TC-08 PASS/clean 2066ms [intent:playwright] results: results/2026-07-20T11-47-02Z/ report: results/2026-07-20T11-47-02Z/report.html # trace · video · logs · screenshots
The problem

Agents re-learn every app, every run.

A natural-language browser agent can test an app it has never seen — but it pays two costs on every run, and neither gets cheaper with repetition.

01  Re-exploration

The agent re-derives navigation, selectors, and timing from scratch each run. Knowledge from run N evaporates before run N+1 — so cost never amortizes.

02  Verdict conflation

When a step fails, the agent can't tell "the app has a bug" from "the app changed and my assumption is stale." It either cries wolf or silently adapts to a regression.

What it is

Explore once. Write a cookbook. Run at O(1-test) cost.

A cookbook (<app>.trif/) is a versioned artifact: recipes, anchors, an app map, and a healing ledger. Any executor runs one recipe from ~1.5k tokens of context and returns one of four honest verdicts — drift detected and named, never silently absorbed.

PASS
oracle satisfied
FAIL-BUG
real defect, evidence-quoted
FAIL-STALE
app drifted — anchor miss
BLOCKED
can't run — never a fake fail
Four doors

Use it however your agent lives.

One artifact, four consumption paths — each a thin wrapper over the same files, results flowing back into the same schema.

1 Agent Skills

A cookbook's router is a valid SKILL.md. Drop it into Claude Code, Codex, or Cursor and the agent auto-loads the workflow.

2 MCP server

Run test-harness-kit mcp and any MCP agent drives the whole loop as tools — read a recipe, run it, get a verdict. Setup →

3 CLI

npx test-harness-kit — for CI, cron, and any shell-capable agent on any model. Zero dependencies.

4 Raw files

It's just markdown + JSON. Read a recipe and execute it by hand — the format floor that keeps every wrapper thin.

See everything

The map, the evidence, and the report — in your hands.

A cookbook shouldn't be a black box. Browse the app's structure, watch what a run did, and read exactly why each recipe passed or failed.

IA map

Reviewable IA map

Surfaces × anchors × recipes, color-coded by freshness, with a detail drawer.

Open the live map →
Run report

Detailed run report

Per recipe: verdict, step trace, oracle checks, timing, and evidence.

Open a real report →
Evidence

Native evidence

Every run leaves a Playwright trace, video, console + network logs, and screenshots.

How it works →
Binding-first runtime

Pay to learn the app. Don't pay to re-run it.

A recipe that passes on the intent lane graduates to a compiled script binding. The next run executes it deterministically — no model, no API key, $0 — and on drift it falls back to the intent lane and heals. A binding failure is a signal, never a verdict.

Intent lane

A recipe runs via the agent/engine against the live app, graded by its oracle.

Graduate

A PASS on a deterministic-ready recipe compiles to a Playwright (and Katalon) binding.

Run at $0

Fresh bindings run with no model. On miss/stale/failure → back to intent + heal.

TestVoyager

A neutral benchmark — reported honestly.

"WebVoyager scores task completion; TestVoyager scores whether a tool can test." Any tool enters via {url, intent} → verdict — TRIF not required, so agents and vendors enter as peers. Results are pre-registered and published whichever way they point. The benchmark →