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.

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.
