PRD. DRD. TRD. — A Complete Agentic Workflow

Every team is reaching for AI right now, and most are reaching for it the same way. Product uses it to write specs. Designers use it to generate screens. Engineers use it to write code. Three teams, three tools, all pointed inward, each getting faster on its own.

Then the handoff happens, and the speed evaporates.

That was us a few months ago. Each layer could produce its piece in a fraction of the old time, and the pieces still didn’t fit. The PRD an agent wrote was great until a designer had to turn it into something real. The design was great until an engineer had to build it. We had automated the easy part, generation, and left the hard part, the handoff, exactly as broken as it always was.

So we stopped trying to make each team faster in isolation, and started building a workflow. This is the story of what we ended up with: three documents, one shared brain, and a set of skills that chain them together.

The first decision was the simplest and the most important. Everything goes in one repo.

One repository for the whole product. Every feature gets a folder. Inside that folder lives the entire story of the feature: the brainstorm, the requirements, the design, the technical plan. Nothing hides in a private Figma file or a buried Slack thread. It all sits in one place that every layer, and every agent, can read and write.

Because it’s Git, this shared brain has two properties we didn’t fully appreciate at first. It has memory, so the reasoning behind every decision is preserved. And it has history, so you can watch a feature evolve commit by commit. The repo isn’t storage. It’s the team’s collective memory, and it gets richer with every feature that passes through it.

Once everything lived in one place, we needed a shape for it. That is where the three documents came from.

PRD (Product Requirements Document). The easy one. Product has always written specs. It answers why we are building something and what success looks like.

TRD (Technical Requirements Document). Familiar too. Engineering has always planned before building. It answers how the thing actually gets made.

The gap was in the middle, and it took us a while to name it. Design had no document. Design intent has always lived in a Figma file, or in a designer’s head, defended live in a meeting. That works fine when the next person in the chain is a human who can read between the lines. It falls apart the moment the next reader is an agent. An agent can’t open your Figma and infer the reasoning behind a layout. It can’t feel that the empty state matters more than the pretty one. If design was going to be a real, automatable layer, design needed to write things down as precisely as product and engineering already did.

DRD (Design Requirements Document). The missing middle. It takes the product’s why and turns it into a design brief: the flows we have to support, the states that must exist, the things we are explicitly not building.

Three contracts, one per handoff:

PRD → DRD → TRD

Each one is the thing the next layer builds against, and none of them is allowed to be vague, because a vague contract is exactly how an agent confidently ships the wrong thing.

Naming the documents was the idea. The recent work was turning them into something that runs on its own. We built two skills for the design layer, and they chain end to end.

Reshape reads the PRD and the discussion logs the product team left behind, and reshapes all of it into a DRD. It reads the reasoning, not just the requirements, because the real why usually lives in the messy conversation and not the clean document. Then it writes a tight design brief back into the feature folder and stops at a gate. Nothing gets designed until that brief is approved.

Render takes the approved DRD, reads the actual product codebase to learn the existing components and tokens and patterns, and builds a high-fidelity, runnable prototype that looks and behaves like it already belongs in the product. Every flow. Every state. It lands in a predictable place, ready for engineering to pick up and turn into a TRD.

Reshape briefs. Render builds. And once they are set up, the entire design layer collapses into two lines:

That is the whole daily loop. You point Reshape at a feature, approve the brief, point Render at the same feature, and a PRD becomes a working design without anyone touching a pixel. The design layer went from a manual bottleneck to two commands.

The part that excites me is that none of this is finished, and the shape of it scales in a few directions at once.

More skills, deeper craft. Reshape and Render are the frame. Into that frame we can plug specialists: a design-system skill so every screen speaks the same visual language, motion and animation skills so the output moves the way it should. Each skill we add raises the floor on quality for every feature that runs through, with no extra effort per feature.

More features, in parallel. Because every feature follows the same structure in the same repo, the pipeline is not a single track. You can run many features through it at once. The system does not get slower as the product grows. It gets more leveraged.

A smarter brain over time. Every feature that passes through leaves its full reasoning behind in the repo. The discussions, the briefs, the decisions. That history is the richest possible context for the next feature. The brain we built literally gets smarter the more we use it.

A pattern that generalizes. There is nothing about this that is specific to us. Any layer that hands an artifact to the next one can become the same three things: a document that acts as the contract, a skill that produces it, and a gate that keeps it honest. PRD to DRD to TRD is just the first instance of a pattern we can keep extending, upstream into research and downstream into QA and release.

The through-line in all of it is that the humans move up. The agents take the production. We keep the specification and the judgment, the questions a machine cannot ask itself, the taste it does not have. The scarce skill stops being the making of the artifact and becomes knowing exactly what to build, and stating it clearly enough that a machine gets it right.