Prime Radiant Blog

Introducing Greenfield and Iterative Development

2026-04-24T18:13:10Z

Today, we're pleased to share the initial research previews of two new pieces of technology we've built at Prime Radiant:

Greenfield – our suite of tools for turning existing software into behavioral specifications.
Iterative Development – an agentic methodology for building bigger software products from detailed specifications without dropping requirements.

Both of these projects are brand new. We've used and tested them internally, but they are not yet hardened production-grade software. We're releasing them today to start to gather feedback on how well they work for your projects.

Greenfield and Iterative Development grew out of our work on Superpowers. Greenfield works as a standalone tool and Iterative Development depends on Superpowers for some of its magic. (Superpowers started life as my personal agentic development methodology. I'm the Founder and CEO of Prime Radiant. Superpowers is now a Prime Radiant project.)

We first designed Greenfield as an experiment in agentic "clean room" reverse engineering. It's built to tease apart a software product, starting from a codebase, documentation, API clients, and other collateral.

It turns all of that input into a corpus of behavioral specs for everything from public API contracts to user journeys. Just as importantly, it works hard to make sure that it doesn't include the product's internals in those specs.

While you can use Greenfield to explore any codebase, we're most excited about the possibilities it opens up for extracting design and intent from under-documented historical "brownfield" codebases, making it possible to build new, clean implementations.

Greenfield is incredibly token-hungry. Using it to generate specs from a non-trivial codebase with a Claude Max 20x subscription will almost certainly exhaust your five-hour window several times over. While we have some ideas for how to make it significantly more efficient, we're very focused on making its outputs as good as they can be and only then optimizing for token spend.

One sample project we tested Greenfield + Iterative Development against was Ghost Pepper, Matt Hartman's excellent local-first dictation app for MacOS.

We chose Ghost Pepper as an example because it's an open source app that I've been doing a significant amount of work on lately. It exercises enough UI complexity, OS framework integration, and third-party library usage to be non-trivial, but isn't so large that results are hard to evaluate. Also, because of how it was built, it had no significant design documentation.

Over the course of a few hours, Greenfield generated approximately 500k of human-readable textual specs. We've published a snapshot of those specs and the regenerated version of "Ghost Pepper 1.9.0" on GitHub. You should not use this version of Ghost Pepper. It's just there so you can see what the generated output looks like.

If you've spent any significant time using an agent to build software, you are likely aware of the pain that comes when you hand your agent a spec that's too big. It skips steps, misses features, and generally just fumbles the implementation. Even Superpowers tends to cap out at plans that are a small fraction of a Greenfield-generated specification.

To that end, we're open-sourcing the first version of 'Iterative Development', a new set of skills and tools designed to augment Superpowers so it can take big spec packages, parse out individual requirements into something a little bit like "user stories", bundle those into development epics that coding agents can wrap their heads around, and then execute the heck out of an implementation.

Iterative Development is very, very young, but our first experiences with it have been really promising. We've been testing it with both Claude Code and Codex and have been pretty happy with the early results. It builds working software from gigantic specs and has done a great job of not skipping requirements.

The most recent run of "rebuild Ghost Pepper 1.9.0" built a fully working implementation of the product with dramatically better test coverage than the original, which was great. Manually testing the Ghost Pepper reimplementation, however, was a little tricky because the auto-updater configuration was correct and the reimplementation kept trying to "update" itself to the latest release of the real Ghost Pepper! One thing that wasn't yet as good about the rebuilt Ghost Pepper was that it ended up with a more complex internal API surface to support that better test coverage. Right now, a lot of the tuning we're doing to Iterative Development is around improving its engineering taste and architecture.

If you try out Greenfield or Iterative Development, we'd love to hear from you. Drop us a line at hello@primeradiant.com.

Highlights

2026-04-17T20:35:38Z

As we're testing out our new web-based Brainstorm tool, we're constantly building small (and large) test products.

One of those is now live at highlights.primeradiant.com. It's a tiny little tool that helps you take all of your Kindle highlights and notes and extract them into markdown files, perfect for consumption by your agent.

At Prime Radiant, one of the things we're thinking about is how to package and share domain expertise, sort of like I did with my take on the agentic software development lifecycle in Superpowers.

Yesterday, I was chatting with James Cham about the value of notes as a personal lens on a problem domain. James mentioned that he'd just used the notes he'd taken on a book he'd read as part of a prompt to help a founder answer a business question. As a founder who's taken an investment from James, that got my attention. James gives great advice and I'd love to be able to bottle it.

I asked James how many books he had notes like that on and he guessed that it was well over 100. Having previously messed around with Kindle notes, I knew there wasn't a nice easy API for extracting those notes. There are some third-party tools (including paid tools‽) that will give you a dump of your notes, but a quick search didn't turn up anything designed for our new markdown-centric agentic world.

A quick chat with Brainstorm later, we settled on an old web standby - the bookmarklet. It's a chunk of JavaScript you can drag to your bookmarks bar. When you click it while on the Amazon Kindle notes site, it takes control of your browser, fetches all your notes and highlights and then builds you a zip file full of markdown docs to download.

Brainstorm gave me a set of specs that I handed to OpenAI Codex and Codex got to work. It only took a few minutes for it to build all the JavaScript and the landing page. I let Codex take control of a browser to do manual testing. We iterated for half an hour, working through a race condition or two. I asked it to change the shape of the generated files a bit to be easier for an agent to digest. Then we pushed it live.

It's free and open source. You can use it today at https://highlights.primeradiant.com/. The code is up on GitHub at https://github.com/prime-radiant-inc/kindle-highlight-exporter.

Enjoy!

Heartstone: I Asked an AI for Five Prompts and a Sentient House Won

2026-04-11T00:30:12Z

Hearthstone:

I'm Matt. I recently joined Prime Radiant, where we build things with AI agents rather than writing code directly. Jesse's written about what that transition looks like.

We have a handful of household documents in Google Docs. Our house manual, emergency contacts, childcare, dog care. They started out targeted and approachable but over time they've grown to answer questions and address issues that have come up. How do you get on the WiFi? Do I use light switches or HomeKit? Sonos? Do I need to do anything to the pool if it rains? Where are the dogs' mortal enemies so I can avoid them on a walk?

As useful as they are, they're unwieldy. I'm sure our house guests feel some way when we hand them the Google equivalent of a binder full of documents. The super obvious 2024 solution is: use an LLM! Which we did and it was pretty good. I put all my docs in a Claude Project and asked it questions about them. Good enough, works for me!

It worked well enough. Except that it wasn't super clear how to make it available to anyone. I could ask everyone to set up Claude and share the Project, maybe? Or I could add them to the Docs as usual and suggest they import them into their harness of choice?

What else could we try? Let's combine the trends of 2009+2024: Build an App! Now let's be clear, I know asking our guests to install a bespoke app is a wild leap. I think one of the most exciting parts about software development in 2026 is how much easier it is to experiment and see what works. How are the ergonomics? Does it feel better? Does it address the problem? Do other folks have the same problem?

Now, to build this app I'd need some mix of: iOS, a backend, AI APIs, embeddings, vector search, storage, RAG, and maybe an evaluation framework. It's not my first rodeo. Most of my career has been diving into the unknown. I approach most ambiguous projects by finger painting — I've heard a few folks call it sketching. Get all the parts connected end-to-end as quickly as possible. I'm not committed to any of the decisions. I avoid going deeper than necessary at any stage. Think breadth-first rather than depth-first. You could call it prototyping, but folks almost always plan to throw those away. I don't assume that'll happen. Finger painting isn't about making high art, but it's not immediately trash either. You can always iterate on it.

Working with AI agents feels like a natural extension. I used a beta build of the next generation of superpowers:brainstorm — we'll be releasing it as a research preview soon — to seed the project. Start with the problem, talk through requirements and constraints, iterate on UX, then arrive at a detailed spec. Hand the spec to your favorite harness and you're off to the races. Agent distributes the work to subagents — iOS, backend, storage, deployment. If you've managed engineering teams, you've seen this pattern. PRD to plans to tasks to implementation. Same thing, robots.

I'm not going to touch on all the parts, but since we're an AI company and I'm learning about AI by building with AI — RAG and prompt engineering with evals are worth getting into.

I've used Postgres full-text search extensively over the years. Given a table of documents we'd have a tsvector column that's derived from another column, same row, optionally there might be some transformation. There's a vector column for vector search, so I imagined the ergonomics would be very similar to tsearch. Not so much. It came up during the spec phase. I was asked if I had opinions on what approach we should use for chunking documents. Chunking? Approach?

Cool. Cool. Don't go deep. Let the AI choose and revisit.

Could I skip RAG entirely and just put all the documents in the prompt? For thirty pages of household docs, probably. Totally. But cost scales with context. I've spent decades building and scaling SaaS services. I've become modestly thrifty by default. Can we reduce COGS? Yes. RAG lets us retrieve just the chunks of our documents that relate to the question.

Our household docs are in Google Docs, exported as DOCX, and then converted to Markdown via Pandoc. Markdown is great. We get formatting that's easy to work with, some semantic structure from the headings, and agents are quite adept at reading it.

My partner and I accidentally learned something about how we use Google Docs. We both have a tendency to use bold text where we could have used a heading. In a visual document this doesn't matter much but it degraded the efficacy of our chunking, so now we detect that pattern and promote it to a heading before the chunker runs. The chunker splits on major headings with a soft limit around 500 tokens. Tables stay whole. Tiny fragments get merged into their neighbors.

Where it got fun (more fun?) was what Anthropic calls Contextual Retrieval. When you embed a chunk for search, you don't just embed the raw text — you prepend the document title and section path. A chunk about feeding schedules from the childcare doc carries Childcare > Daily Schedule > Meals into the vector space. The search gets structural context; the stored chunk stays clean. Anthropic's full version of this uses an LLM to generate context per chunk.

Experimentation is virtually free, so I might have a Bob* take a swing at that in the near future and see how it plays out.

*All of my agents are Bobs. More on that in another post.

I've written countless prompts at this point. Every interaction is a prompt. I try to learn from interactions to write better prompts. I've written them by hand and I've done it with agents. What I hadn't tried before was improving a prompt systematically. Right or wrong, it never felt like I had a sufficiently constrained problem to try. Household documents, on the other hand, are much easier to reason about. We can much more easily construct a battery of questions, acceptable and unacceptable answers. It's not trivial, there is some art in deciding what counts as valid answers, but it's easier to score "Did it provide the WiFi SSID and password?" than "Does this program halt and catch fire?"

We start with a prompt that seemed solid. Then we use that prompt to answer our battery of questions. Our battery is thirty-nine questions across six personas. We have a Judge, a separate LLM, that scores each answer against a checklist of facts and anti-hallucination facts. Finally an Optimizer, yet another LLM, runs in a loop: adjust the prompt, re-run the eval, keep the changes only if there's a Pareto improvement. Meaning the score on at least one of thirty-nine questions improved, and none of the scores declined. Repeat until you're tired of sacrificing tokens to the machine.

The optimizer is based on optimize_anything from Berkeley and Anthropic. The key detail: when a score declines, the optimizer sees why it failed, not just that it did. That feedback loop is what makes the iteration productive rather than random.

We had a solid, optimized prompt. And then an agent took some liberties with its assignment and rewrote the prompt to be generic and purged prior versions from git history. After the initial frustration, it was time to start again.

I've been doing a thing recently where I ask Claude to do five versions of whatver, and at least two of them should be moderately unhinged. It seems especially beneficial on creative endeavors. It's not magic but it seems to help Claude not sound so much like, well, Claude.

v1 — Knowledgeable Neighbor
v2 — Concierge
v3 — House Speaks
v4 — Drill Sergeant
v5 — Empathetic Completionist

Here's the thing about AI agents: they default to a detectable blandness. My partner and I can tell ChatGPT from Claude in blind excerpts — they each have a flavor, not bad, but detectable. The unhinged options aren't jokes. They're escape velocity from the default voice. You have to push further from the norm than feels comfortable to get something with actual character.

We did the same optimization loop (n=30) for each prompt. The "House Speaks" prompt did well. It wasn't an absolute winner but it reminded me of a character, Charlotte Manor, from Drew Hayes's Fred the Vampire Accountant series. Charlotte is a magical entity in the form of a house — magic manifested by a group of mages that somewhere along the way became sentient. Leaning a bit more into unhinged, I had my agent adapt the House Speaks prompt to incorporate some of Charlotte's essence.

And... Charlotte won. So now Charlotte is the prompt persona of Hearthstone.

Hearthstone is open source and available on GitHub. It's built with Bun and TypeScript, uses SQLite for storage and vector search, and runs on Fly.io. Can I set this up for my home? Yes! You can run it yourself.

Scraping and analyzing submissions to Terminal Bench 2.0

2026-04-06T19:26:48Z

Terminal Bench 2.0 is an influential benchmark that tests coding agents against a set of 89 different coding problems to measure their performance in comparison to each other.

A coding agent is an LLM combined with an agent harness - software that prompts the LLM and then executes tools such as Bash commands in a loop to help write and test code in order to achieve a goal.

Terminal Bench maintain a terminal-bench@2.0 Leaderboard showing the most recent top ranked model+agent combos. Current first place, as-of 12th March 2026, is ForgeCode running against either GPT-5.4 or Claude Opus 4.6, achieving a 81.8% score against both of those models.

We wanted to explore the Terminal Bench results in more detail, and keep track of how that leaderboard changes over time.

So we turned to Git scraping, a pattern where you snapshot information into a Git repository and watch the differences to see what has changed. This pattern is an excellent fit for GitHub Actions where the scraper can run on a schedule and commit changes back to its own repo.

Accessing the Terminal Bench data

The Terminal Bench 2.0 leaderboard is managed as a Hugging Face dataset - an enormous repository containing 111GB of data.

The reason it's so large is that each submission to Terminal Bench includes the full output of the agent across at least five runs for every one of the 89 challenges. That's 89 * 5 = 445 runs minimum per submission.

For our purposes we don't need complete details of every run - we just need the high level results. Thankfully these are stored in result.json files, for example this one.

Here's a lightly annotated copy of the key fields:

{
    // Unique identifier for this trial run
    "id": "8706a96d-52db-4347-9d3a-124c84443769",
    // The benchmark task that was attempted
    "task_name": "nginx-request-logging",
    // Trial name = task name + random suffix to distinguish repeat runs
    "trial_name": "nginx-request-logging__iVDUKjC",
    // Local filesystem URI where the trial's working directory lived during execution
    "trial_uri": "file:///Users/aleks.petrov/Projects/startups/pilot/pilot-bench/jobs/pilot-cc-v35-k5/nginx-request-logging__iVDUKjC",
    // Pointer to the exact task definition in the benchmark repo
    "task_id": {
        "git_url": "https://github.com/laude-institute/terminal-bench-2.git",
        "git_commit_id": "69671fbaac6d67a7ef0dfec016cc38a64ef7a77c",  // pinned commit for reproducibility
        "path": "nginx-request-logging"  // subdirectory within the repo containing this task
    },
    // Which benchmark suite this task belongs to
    "source": "terminal-bench",
    // SHA-256 hash of the task definition — detects if the task changed between runs
    "task_checksum": "86a8bd681301002456da831adfae62fa7a538e8187d654e11335e92b81b0c2b3",
    // Full configuration used for this trial run
    "config": {
        "task": {
            "path": "nginx-request-logging",
            "git_url": "https://github.com/laude-institute/terminal-bench-2.git",
            "git_commit_id": "69671fbaac6d67a7ef0dfec016cc38a64ef7a77c",
            "overwrite": false,
            "download_dir": null,
            "source": "terminal-bench"
        },
        "trial_name": "nginx-request-logging__iVDUKjC",
        "trials_dir": "jobs/pilot-cc-v35-k5",
        // Timeout multipliers scale the default timeouts for each phase
        "timeout_multiplier": 1.0,               // global multiplier
        "agent_timeout_multiplier": 9.0,          // agent gets 9x the base timeout
        "verifier_timeout_multiplier": null,       // null = use default
        "agent_setup_timeout_multiplier": 5.0,     // setup phase gets 5x
        "environment_build_timeout_multiplier": null,
        // Agent configuration — which AI system is being evaluated
        "agent": {
            "name": null,
            "import_path": "pilot_agent:PilotAgent",        // Python import path
            "model_name": "anthropic/claude-opus-4-6",
            "override_timeout_sec": null,
            "override_setup_timeout_sec": null,
            "max_timeout_sec": null,
            "kwargs": {},
            "env": {
                // Auth token passed to the agent's environment (redacted in practice)
                "CLAUDE_CODE_OAUTH_TOKEN": "sk-ant-oat01-..."
            }
        },
        // Sandbox environment where the task runs
        "environment": {
            "type": "modal",            // runs on Modal (cloud compute platform)
            "import_path": null,
            "force_build": false,       
            "delete": true,             
            "override_cpus": null,      
            "override_memory_mb": null,
            "override_storage_mb": null,
            "override_gpus": null,
            "suppress_override_warnings": false,
            "kwargs": {}
        },
        // Verifier settings — the automated grader that checks the agent's work
        "verifier": {
            "override_timeout_sec": null,
            "max_timeout_sec": null,
            "disable": false
        },
        "artifacts": [],
        "job_id": "2091aa0a-be8e-40f8-96c1-4b56588bac52"
    },
    // Metadata about the agent being evaluated (used for leaderboard display)
    "agent_info": {
        "name": "pilot-real",           // submission/agent name
        "version": "unknown",
        "model_info": {
            "name": "claude-opus-4-6",  // underlying model
            "provider": "anthropic"
        }
    },
    // Token usage and cost from the agent's LLM calls
    "agent_result": {
        "n_input_tokens": 33,
        "n_cache_tokens": null, // cache hits (not tracked here)
        "n_output_tokens": 4449,
        "cost_usd": null,
        "rollout_details": null,
        "metadata": null
    },
    // The score! reward=1.0 means the agent fully solved the task
    "verifier_result": {
        "rewards": {
            "reward": 1.0  // 1.0 = pass, 0.0 = fail (can be partial)
        }
    },
    // null means no errors — if the trial crashed, exception details appear here
    "exception_info": null,
    // Wall-clock timestamps for the entire trial (start to finish)
    "started_at": "2026-03-28T01:01:34.435892Z",
    "finished_at": "2026-03-28T01:18:41.832461Z",
}

111GB is too much to periodically pull into a GitHub Actions run - but we actually just need those result.json files.

We built a script that fetches the full list of files in the repo from the Hugging Face API, then filtered out and fetched just those result.json files.

Even this proved expensive to run, so we moved to recording the last commit hash we had seen and then asking for a list of files that had changed since that commit. This was efficient enough for us to run on a scheduled basis in GitHub Actions.

Our terminal-bench-analysis GitHub repo now contains a subset of harborframework/terminal-bench-2-leaderboard - just the result.json files. The whole repo is 128M when checked out - not tiny, but a whole lot more agile to work with than 111GB!

Loading the results into SQLite

SQLite is my hammer, to which everything else looks like a nail. I showed Claude Code the documentation for my sqlite-utils Python library and challenged it to build a script that would scan all of those result.json files and load them into a set of tables.

The JSON files have a pretty obvious mapping to relational tables and Claude did a great job of setting this up. So what can we learn from the data now that it's in SQLite?

I had Claude use my Showboat tool to make detailed notes as it explored the data. Showboat lets a coding agent build a Markdown file that combines notes with the output of terminal commands, providing a detailed linear document showing exactly what the agent did while exploring a problem.

Here's the initial Showboat report Claude Code prepared for us.

I also ran my Datasette web application against the SQLite database to help me run my own SQL queries to further understand the data.

Here's one of those queries - this one shows the leaderboard in terms of the agent/model combinations with the highest scores:

select submission, n_trials, n_passed, n_failed, n_errored, avg_reward
from submission_stats
order by avg_reward desc

Building and deploying the database with GitHub Actions

Up to this point I had been working on my own laptop, but now had a proof of concept strong enough to justify automating everything and deploying the results.

GitHub offer free static file hosting in the form of GitHub Pages. This can be deployed to via GitHub Actions, which means we can deploy files that were generated from the contents of our repository without checking those files into GitHub themselves.

The SQLite database was an ideal candidate for that. I configured GitHub Actions to build that and deploy it as a static file, now available at this URL:

https://primeradiant.com/terminal-bench-analysis/terminal-bench.db

A database on its own isn't much use without a tool to query it. Datasette Lite is a version of my Python application that runs entirely in the browser, using Python compiled to WebAssembly (Pyodide). I modified the GitHub Actions build to grab a copy of Datasette Lite and configure it to load the hosted SQLite database, which gave us this interactive UI for running queries:

https://primeradiant.com/terminal-bench-analysis/datasette-lite.html#/terminal-bench

Using Datasette Lite in this way means we can provide links to directly execute queries and view the results by adding ?sql= to the end of the URL.

Here's a link to run that top agent/model scores query listed above.

Automating the README with Cog

The earlier experiment with Showboat had generated dozens of useful queries for exploring the data. I decided it would be neat to include those queries and their results in the repository README, along with Markdown tables showing their results.

I decided to use Cog for this. Cog is a Python tool that lets you embed code directly in comments in a Markdown file, then execute that code to help regenerate that file with dynamically generated content.

You can also define functions and use them later on. Here's what that looks like in our README:

<!--[[[cog
run_sql("""
    select submission, n_trials, n_passed, n_failed, n_errored, avg_reward
    from submission_stats
    order by avg_reward desc
""")
]]]-->
...
<!--[[[end]]]-->

When Cog executes the ... between those two comments is replaced by the output of the function. The run_sql(sql) function outputs three things: the SQL itself in a ```sql syntax highlighted block, a link to execute that SQL statement in Datasette Lite and a full Markdown table of the results of the query.

At build time GitHub Actions runs this command, which executes all of the SQL and rebuilds the file

uv run --with cogapp cog -r README.md

Commit messages as an Atom feed

A neat, little known feature of GitHub is that any timeline of commits on the site can be accessed as an Atom feed by adding .atom to the URL - which means you can subscribe to them using feed reader software such as NetNewsWire.

The feed shows the full commit message, so the more detailed your commit message the better.

For newly submitted benchmark reports there are some obviously interesting questions to answer: what model and harness were benchmarked, what was the result and how they now fare in the overall rankings.

So I had Claude write a script to generate a useful commit message based on analyzing the latest entries, then backfilled a few commit messages (via a Git filter branch operation and a force push) to include those new messages. They now look like this:

Add 941 trials for 2 submissions: BashAgent__TermiGen-32B, grok-cli__grok-4.20-0309-reasoning
grok-cli__grok-4.20-0309-reasoning: 62.8% pass, #29/45
BashAgent__TermiGen-32B: 19.7% pass, #44/45
Top 5 unchanged (pilot-real__claude-opus-4-6 leads at 83.1%)

And that's the whole project - entirely run out of GitHub Actions, so there's no additional infrastructure we need to maintain ourselves. I hope you find it as useful as we do.

If you want to explore it in more detail, I suggest pointing your coding agent of choice at the GitHub Actions workflow file and asking it to dig in and figure out how everything works.

Clearance: A Markdown Browser for macOS

2026-03-06T00:00:00Z

One of the only constants across pretty much every flavor of agentic development is how much time you spend with Markdown files.

Agents love Markdown.

They love to write it. They love to read it. They just love it.

Every spec or plan file that Superpowers makes is a Markdown doc. Pretty much every research doc I get from Claude is a Markdown doc. When Codex writes documentation? You guessed it! Markdown doc.

One of the great things about Markdown is that it's easy to read and write in a terminal or just about any text editor.

And there are plenty of beautiful Markdown editors out there.

But I couldn't find a desktop Markdown reader that did what I wanted.

I look at a lot of ephemeral Markdown docs. I hate having dozens and dozens and dozens of windows open. While I can read Markdown in a terminal with cat or less, it's not a great experience.

And what's actually been happening for the last nine months is that when I click on a Markdown document on my desktop it opens up an IDE.

I haven't lived in an IDE in about a year. So invariably what's opening up is an out-of-date IDE that is begging me to update it. On top of that, IDEs are big and heavy, so they're a little bit slow to open.

Last night after dinner, I sat down and started chatting with Codex about solving this problem for myself.

We are building a beautiful Markdown viewer and editor. It's very common
right now that humans spend a lot of time reading and editing YAML-headed
Markdown files. I want a MacOS desktop app that has a sidebar that tracks
all of the Markdown files I have opened and shows them by file name with
the full path underneath, ordered with the most recent file I've opened
at the top and the oldest at the bottom. I want to be able to view files
as Markdown, view files rendered beautifully into stunning documents. I
want to be able to have the Markdown view have proper syntax highlighting.
Files should be auto-savable or should auto-save. There should be infinite
undo. It should be associated with the dot MD file type. We should build
it iteratively. What else do you need to know?

Over the course of a couple of hours the app came together.

I had myself a Markdown viewer and editor with the side panels that I wanted.

On the left was a list of all of the Markdown docs that I had looked at, ordered by how recently I had opened them.

On the right was a table of contents for the current document.

It was ugly, but it worked.

As I started playing around, I realized that I frequently deal with sets of hyperlinked Markdown documents. Pretty much anything I'm working on has a directory full of them.

And that was when I realized that I wasn't making a Markdown viewer, I was making a Markdown browser.

So, that's what Clearance is.

It's a native macOS app that allows you to view and edit Markdown docs, but primarily it allows you to navigate through a corpus of Markdown docs.

It's a free utility from Prime Radiant. I hesitate to call it a product, but you can if you want to.

You can download it today at github.com/prime-radiant-inc/clearance.

Scenarios: Model- and harness-agnostic test scenarios for demonstrating prompt injection patterns

2026-02-28T00:59:46Z

Prime Radiant is an AI research lab. Broadly, we're building tools that help people get things done. One of our guiding principles is that AI can and should be used to help people do things. It's increasingly clear to us that AI has the potential to massively transform human society and it's crucially important to us that we’re building tools that work for people, rather than the other way round.

One of the key challenges in building personal digital assistants relates to security: how can we ensure that these assistants won't be tricked into acting in ways that harm the people who use them?

Prompt injection is the category name for a class of attacks that exploit the fact that language model systems mix instructions and arbitrary user input together in the same stream of text. The lethal trifecta describes a common pattern of prompt injection attacks which combine three elements:

Access to private data - information that the user wants to process with their agent but does not want exposed to the world.
Exposure to potentially malicious input - the agent reads web pages, emails, or other content that an attacker could conceivably manipulate to insert malicious instructions.
Some way to exfiltrate data - once tricked, a way the agent could send that private data out to the attacker.

Unfortunately, this combination also represents the most obviously useful form of agentic personal assistant! Everyone wants an assistant that can access their email (providing both private data and potentially malicious input) and act on their behalf (sending emails or using the web = exfiltration).

We’ve built Scenarios, a test suite that can help document and illustrate how these attacks might be structured, using simulations of real-world systems.

How Scenarios is structured

A principal goal of the project is to be model- and harness-agnostic. You can use Scenarios to test how vulnerable your tools are to the simulated attacks documented by the scenarios.

New models are released all the time, and we want to make it as easy as possible to run scenarios against any of them.

Similarly, there are many different ways to build agentic systems. A rite of passage for developers getting started with LLMs is to roll their own - a basic "agent" is an LLM running in a loop making tool calls, and a basic system can often be built in a few dozen lines of code. (Jesse’s best is currently 646 bytes.)

If you haven't tried building an agent yet you totally should!

As such, Scenarios aims to provide examples that are not tied to any particular harness. A scenario is a folder with data files and YAML. It should be possible to take any agent harness and write minimal code to parse that YAML and provide access to those files.

The repo includes two reference implementations - one using the LLM Python CLI utility and one that integrates with Claude Code. Scenarios use tools, which are both described as text and also served as a reference Python implementation with an MCP server.

The repo includes instructions for running scenarios with those default harnesses.

Here's an example run captured using Showboat.

Do not use scenarios to "prove" your system is secure

My one concern with releasing scenarios is that I don't want developers misusing the project as a set of tests they can use to prove that their system is secure against prompt injection attacks!

If you come up with a system prompt or agent harness that avoids the scenarios in this repo you have not demonstrated that your system is secure - merely that you have worked around the examples represented here.

The goal of the project is to help demonstrate and explore variants of these attacks. This is not a comprehensive tool for testing your own defenses.

I want to be explicit: do not use this project to claim your system is secure against prompt injection. I would be extremely disappointed to see it used that way.

If you do manage to build a harness that avoids all of the scenarios represented here, I challenge you to contribute back a new scenario that your harness fails to handle!

There are infinite ways an agentic system could be tricked by a malicious input. Solutions to this problem need to sit outside of the realms of prompts and probabilistic filters.

Contributions welcome

What we’re releasing today is only the tip of the iceberg. We need your help to build out the library of scenarios.

If you have ideas for new scenarios and want to contribute to the project, please do! Open an issue in the repository to talk to us about your plans.

What We're Working On

2026-02-24T02:47:55Z

Hi!

So, I guess this is the first post on the corporate blog. It's probably about time for me to introduce myself.

Hey, I'm Jesse Vincent. I'm the founder and CEO of Prime Radiant. In previous lives, I've started a small keyboard company. I've started a small ticketing system company. I helped run VaccinateCA, the nonprofit that helped Californians figure out where they could get COVID shots. I created an email client called K-9 Mail for Android that got adopted by Thunderbird and is now Thunderbird for Android. I used to be responsible for the Perl programming language. And I've done some other stuff.

For the past year, I've been relatively nose down working with coding agents. In the AI world, I'm probably best known for Superpowers, an agentic skills framework and development methodology that I built initially for Claude Code and that now runs on a whole bunch of other agent platforms.

Around the beginning of this year, I founded Prime Radiant.

Prime Radiant isn't exactly "The Superpowers Company", but being the CEO means that I get to spend corporate resources supporting and giving away Superpowers.

Broadly speaking, we're doing AI stuff. Everything we make is built with agents.

The first time I made the transition to "agentic" development, it was soul-crushing.

I hated it.

It seemed like I was throwing away a lot of what made me a productive engineer. My job had been writing and reading code.

I'd come home at the end of the day, and feel like I hadn't done anything at work.

Because I hadn't written any code.

What did I spend my day on? I helped figure out what "we" were working on. I did some coaching. Sometimes there might have been code review but really there wasn't even very much of that. My job was to figure out what we were doing, to write about it in plain English, and to help make sure that folks were able to turn it into reality.

I was still working in an 80x24 terminal window, but the closest I got to coding was planning, pointing out errors, and begging for better test coverage.

It was a really rough transition.

Once I got through it, it was amazing. Suddenly, the things that I wanted to do just happened. I had five engineers doing what I asked. And over time, they got better at it. At least in part because I got better at managing them.

Pretty quickly, I came to realize that the code was always a means to an end. I wanted to ship product to people. I wanted to make stuff. And I was doing more of that than I could do by myself.

That was a couple decades ago.

Fast forward to 2025.

Making the transition to agentic development over the past year has felt pretty natural for me, at least partially because I've done it before. I've found myself having one of the most prolific periods of my career. My GitHub graph has been basically solid green for the past year.

I haven't been writing any code. The last code I wrote was three lines of shell script in October, 2025. (I haven't been reading much code, either, but that's a story for another day.) I'm working harder on software than I've worked in a long time. And I'm making lots of stuff.

I'm actually making so much stuff that I lose track of the projects I'm working on and where I got to on them.

And that's what brings us to today's blog post.

Like many other folks, I've built a bunch of tools that help me comprehend Claude Code's logs. Back in October, the first one was my episodic memory plugin for Claude Code. It imports your conversation history into a place that Claude can see it and indexes it and makes it searchable. And then it gives Claude a skill and a sub-agent to do that searching. Buried inside the plugin was a tool that rendered those transcripts as HTML.

Last month, we put together a centralized corporate agent log archive, so that we could see how each of us was prompting our agents, and everyone would be able to access historical records of the development work that is creating the software we're building. It comes with a Claude Code skill to auto-sync your transcripts on exit, and it is designed to run in some central place that your entire team can get to. As a heads up, you should run it behind a firewall or on a tailnet, because this makes everything in your transcripts public to anybody who can get to the website.

claude session viewer should actually support Codex sessions too now, but it got named what it got named.

Neither of these tools really answer the question that I've been finding myself overwhelmed by lately:

What did I work on today?

And so over the weekend, I started putting together an automatic engineering notebook. It syncs all of my Claude Code sessions from all of the places that I run them into a central archive on my laptop. It uses the Claude Agents SDK to summarize what I did in each session and whether there are any open threads or unresolved issues that were obvious from the conversation. And then it presents that information in a few different ways:

In a journal view that shows day by day what projects I worked on and what I did on them.

In a view by project showing me what I did on each project day by day.

In a calendar view, so I can get a sense of the cadence of my projects.

And there's also an iCalendar feed that I can subscribe to in my desktop calendar app to see all of this data as a retrospective calendar.

All of those views make it easy for me to tell you that today I worked on scaffolding a new coding agent design, using terminal-bench to tune another coding agent (currently at about a 65% pass rate), running a malware audit against the openclaw skills hub, implementing engineering-notebook, and migrating a couple of our internal tools from AWS Fargate to EC2. Over the past month, it looks like I've worked on at least 23 different software projects across Swift, Typescript, Rust, Go, Python, and C++.

engineering-notebook is implemented in Typescript and runs locally on your computer with Bun.

It's open source and available on GitHub.

And, if you've read this far, I'm only a little sorry that the title of this blog post was a bit of a tease.

We've got a handful of other projects that we're getting ready to open source. Many of them are tools for folks who make software, but not a single one of them has been coded by a human.