Evolving the RDR Process

For the last year I have been experimenting with a specification-first LLM (agentic) development model I’ve been calling Recommendation Decisioning Records or RDRs. You can read about the genesis to get more context.

Arcaneum was written using early “versions” of the RDR template, as well were a few internal projects.

This year I’ve started a new project that is a lot more ambitious and realized I was using/creating a lot of ceremony (copy/paste) as I revised any given RDR, iterating it through to the final stage (the stage right before implementation). This became quite tedious. So a couple of things happened.

First, using Arcaneum, I indexed a large amount of research on specification-driven development, both old and new, and devised a few prompts that would better formalize how I was, by hand, hardening the specifications. I tend to write a few at a time before implementation since they usually represent architectural layers, so hardening them in isolation and against each other was important. This worked quite well and led to fewer iterations or inconsistencies found within a given RDR during the implementation phase.

Of note, one primary benefit of the RDR process is moving from a NxM model to a Nx1xM model. Instead of lots of iterations against a large number of files, I iterate more against a single file, which is used to generate a large number of files or edits. And the seams between the RDRs are also validated as much as they can so they can be built in tandem.

I also formalized a “launch” implementation prompt (research based) to drive implementation with further hardening and TDD best practices.

After quite a few more rounds, I decided to index my Claude Code sessions in Arcaneum and mine them for additional ad-hoc patterns I was using to see if I could formalize even more of the process.

This landed me with additional steps to the process, which all can be found on the Github repo.

The README is a great place to start, but make note of the RESEARCH behind every element of the flow.

The process is still evolving, but the flow captures more data that can be used to continue to refine the process.

I’ve also experimented with the Superpowers skills on smaller projects. I like the worktree tool a lot and have directed a few skills to only work in worktrees now that it’s more stable and streamlined. But the specification-first model provided by Superpowers isn’t as robust for complex systems with lots of interacting layers. I’ll continue to use Superpowers for smaller or more throwaway projects, but not for projects that require a lot of upfront research and nuanced behaviors.

Arcaneum is part of my everyday workflow. From competitive analysis and focused research to iterating on research-driven RDR specifications. I’m using the stella embedding model for pdfs and md usually, but it depends on the size of the corpus. My general research corpus (PapersFast) uses minilm for embedding and has 3586 documents. But I usually re-index a subset (after searching PapersFast) into a new corpus using stella. For source code I use jina-code.

Keep an eye on the RDR repo, I do want to convert things to skills etc, but there are so many touch points that require human judgment (which is the point of it all) that I’m unsure it would be any easier to deploy and iterate with.