Every verification began the same way: a few lines of Python over a 20 MB JSON file, slightly different each time.

Verifying an engineering change against production records meant pulling out the same dozen things from a 10 to 20 MB JSON file: stage timings, spend against the ceiling, which execution paths ran, per-condition counts, the served lead text. Each time, the session wrote a small script to do it. Each script consumed context, each was slightly different from the last, and comparisons against the previous record were done by eye.

A fixed, spec-driven summary makes a verification a one-liner and keeps the session's context small. That is Record Lens. Because the spec lives in the project, the plugin knows nothing about any project.

The Record Lens repository on GitHub at its first release

What it does

/record <file> [baseline]

It reads the record, resolves each field of the spec under an optional root path, renders it by kind, and, when a baseline is given, prints before and after for every field that differs along with a count of changed fields.

There are five kinds of field:

  • value: the JSON at the path, cut to a maximum number of characters;
  • text: a string with its whitespace collapsed;
  • count: the length of a list or object;
  • keys: an object's keys;
  • table: a list of objects, one line each, with the columns named.

Setup

The spec is a small file in the project, committed with it so every session and subagent sees the same one:

{
  "root": "response.answer.provenance.gie_answer",
  "fields": [
    { "label": "timings", "path": "timings", "kind": "value", "max": 300 },
    { "label": "spend", "path": "request_budget.spend", "kind": "value" },
    { "label": "paths", "path": "interpretation.operation_results[0].paths", "kind": "keys" },
    { "label": "per-condition counts", "path": "interpretation.operation_results[0].identification.per_condition", "kind": "table", "columns": ["text", "counts"] },
    { "label": "lead", "path": "../../items[0].data.text", "kind": "text", "max": 600 }
  ]
}

Paths use dotted keys and [n] indexes. The .. form is not supported: put fields that sit outside the root under their own spec entry with the root omitted, or use two specs.

Installing it

Install once, at the user scope, from a Claude Code session:

/plugin install record-lens --marketplace William-Harvey/record-lens

Answer yes to add the marketplace, then pick the scope. From a shell:

claude plugin install record-lens --marketplace William-Harvey/record-lens

In the desktop app, click the plus next to the prompt box, choose Plugins, add the marketplace William-Harvey/record-lens, then add the plugin. To try it without installing:

claude --plugin-dir <path to the plugin folder>

Start a session in the project and the command appears under /, for the session and every subagent it launches.

Why I'm sharing it

Any system that writes structured run records, whether evaluations, pipelines or agent runs, faces the same chore: the same dozen fields pulled out by hand, differently each time, before a change can be judged. A spec file per project turns that into one command and a stable diff. The plugin knows nothing about my records. Yours are described in your spec.

It is on GitHub under the MIT licence at github.com/William-Harvey/record-lens.