rks for Product and Design — Governed Thinking, Not Just Governed Code

Who this is for

The architecture post described rks for the people building it. This one is for the people deciding what gets built and whether it is right: product managers, designers, and design leaders.

The claim is simple. rks is not only a way to ship code faster. It is a governed process for product and design thinking — a way to take an idea in plain language and turn it into scoped, cited, reviewable work, with the reasoning attached and the cost visible. You do not need to read code to drive it. You need to describe outcomes and review results.

Everything below is grounded in what rks actually does today. Where something is direction rather than shipped, it is labeled as such — plainly, in the text, not in a footnote.

1. From a sentence to a real product backlog

You describe work the way you always have: "Let people reset the calculator display." What comes back is not a vibe and not a wall of generated code. It is a well-formed story — a Problem statement, a Solution sketch, explicit Acceptance Criteria, and a list of the files the work will touch.

That is the job of the PO Governor — a product-owner step that runs as a real, structured pass, not a text-completion trick. Before it writes anything, it researches the project: it looks up the relevant parts of the codebase and existing notes so the story is grounded in what is actually there. The acceptance criteria come out as checkboxes you can read and argue with:

## Acceptance Criteria
- [ ] Calculator renders number buttons 0-9
- [ ] Clear button resets the display

The point for a PM: the story is anchored to reality from the first draft. File paths are real because they came from research, not from a guess. Requirements are grounded because the agent read the project before proposing them. You are reviewing a well-formed artifact, not cleaning up after a hallucination.

2. Scoping as a discipline, not a habit

Good product scoping is the difference between a story that ships and a story that sprawls. rks builds that discipline in as a rule: decompose by concern.

A concern is one coherent thing to change. A single concern can carry several acceptance criteria and touch several files and still be one story. Two unrelated changes bundled together are two stories, however small each one is. That judgment — recognizably a product judgment — is made explicitly, and it is cited: for each concern, the PO Governor names which acceptance criteria and which files belong to it.

The rules that follow are the ones a disciplined product owner already keeps:

A gap that is the same concern — the change rippling into another layer or caller — is pulled into scope, not left dangling.
A genuinely independent concern is deferred to a follow-up story, never quietly merged in.

This discipline is real in rks today. Stories are scoped tight — one concern each — and the PO names the concerns as it goes. What is still ahead is the automated version: the agent working out the concern breakdown up front, on its own, before it plans. That is coming, but it is not there yet. Today the discipline ships because the stories are kept small and coherent, not because a machine decomposes them for you.

3. A pipeline you can actually see

Every unit of work is a story, and every story has a phase. It moves through a fixed, visible sequence:

Rendering diagram...

Each arrow is a real gate, not a status someone remembered to update:

draft → ready: the story is not "ready" until it has target files and testable requirements. QA adds those. No test requirements, no promotion.
ready → arch-approved: a review gate the story has to pass before anyone builds it.
the rest: planning, execution with tests, and shipping — each a deliberate transition, not a field a human toggled.

For a product or design leader this is the part that quietly matters most. Status is observed behavior, not self-reported. A story cannot claim to be ready without the artifacts that make it ready. When work finishes, the story is archived to a permanent record — a queryable history of what shipped and how it got there. You get an audit trail for free, because the pipeline produces one as it runs. Stories can also move backward — regress to ready — when a later step surfaces a problem, so the board tells the truth even when work turns out not to be done.

4. Rationale you can trace, not rhetoric you have to trust

The most expensive thing a design tool can do is sound confident while being wrong. rks is built against that.

Decisions in rks are grounded in project knowledge and cited back to it. The research layer distinguishes notes that describe reality from notes that describe intent, and treats the record of what actually shipped as ground truth — so the system will not tell you a feature is "not built" because an old planning note still talks about it in the future tense. Design rationale points at a source. When you ask why a story is scoped the way it is, or what an existing behavior does, the answer arrives with a citation you can open.

For a designer or PM, this is the difference between "the AI said so" and "here is the note that says so." Rationale becomes reviewable. Disagreement becomes possible, because there is something specific to disagree with.

5. Research as a first-class capability — evidence, not vibes

Research is a first-class, shipped capability in rks — not roadmap, and the part a PM or designer will reach for most. It runs in two directions: inward, into your own knowledge, and outward, into the world.

Inward — grounded in what you already know. You can ask rks a question about your own project and get a cited answer instead of a guess: how does this work, why is this scoped the way it is, what is our precedent, what did we decide before. rks searches your project's own notes, code, and history — its knowledge graph — and answers with the specific notes it drew from. This is the machinery behind grounded, cited rationale: it is the thing that goes and gets the citation.

Outward — grounded in the world. The external research agent reaches outside the project, to the web and external sources. For product and design this is the headline. Competitive and market analysis, UX and design best practices, user-research synthesis, design patterns, library and API and reference docs — evidence from the outside world, on demand, and returned with its sources attached. This is real and has been used effectively on live client work, not a demo.

Rendering diagram...

Two modes, both useful. Sometimes you just need to know: ask, get a quick inline answer with its citations, move on. Other times you want an artifact — a durable, cited research document you can review, hand to a stakeholder, and reuse later. rks does both. In document mode the research is written to a note and folded back into your project's knowledge, so it becomes a reusable asset rather than a throwaway chat — and the next question can build on it.

The payoff is product and design decisions grounded in both your own accumulated knowledge and the outside world. Evidence-based, not vibes. Every claim carries a citation — an internal note or an external reference — so it is reviewable and arguable, held to the same standard as the rest of rks. You are not asking the model to sound right; you are asking it to show its sources, and it does.

6. Design through docs — what works today, and where it is heading

This capability has two layers worth keeping straight. Some of it is working today: rapid prototyping, Figma wired to the agent through MCP, and driving a real browser with Playwright to take a first pass through a flow. Some of it is where this is heading: design-through-docs as testable experiments — an A/B and research surface — and a polished, automated visual-QA agent. Only the design-through-docs-as-experiments epic is genuinely VISION; the prototyping and design-tooling pieces are things the owner has actually run.

Start from something rks does today: notes and docs are first-class. They are not a byproduct of the work; they are the substrate the work is grounded in. A design doc in rks can carry not just prose but proposed or executable code — a description of current-state or future-state behavior that the system can actually reason about.

The design-through-docs experiment surface — VISION, no implementation committed — follows from that: if a design doc can express variants — two proposed versions of a flow, a component, an interaction — and rks can materialize them, then documentation itself becomes the source for A/B and multivariate splits. Design thinking, expressed as a doc, becomes testable. Qualitative and data-backed research stops being a separate downstream activity and becomes something the design artifact can seed directly.

That direction still carries honest open questions: how a variant is defined in doc terms, where the boundary sits between "proposed code" and "deployed experiment," and how assignment and signal recording work. It is a design pass, not a feature. But it points somewhere real: the design doc as the unit of experiment, not just the unit of description.

The loop that would make testable design concrete

If design-through-docs is the idea, a prototype-to-validation loop is how it becomes practice. Here is the shape — with each piece marked for what it is today:

Rendering diagram...

Prototype fast — proven. Rapid prototyping is an established rks use case. The ux287 work is precedent: the stated aim there is to compress delivery cycles "from months to days" through reusable scaffolding and AI-assisted authoring. You describe a screen or flow in chat; rks scopes and builds it. This part is real today.
Wire design tools (Figma via MCP) — works, and it is a genuinely good workflow for PMs and designers. You connect Figma to the agent through MCP, pull design context straight into the work, and drive prototyping from it — the design and the build stay in the same conversation. This has been used in real rks projects and it delivers. Roadmap aside: today it takes a bit of per-session setup; making it a one-click default is on the roadmap.
Take a first UCD pass with a bot — works today. rks can drive a real browser through Playwright: click through a flow, exercise the screens, and take a first user-centered-design pass for you before a human ever sits down with it. Want a bot to walk the happy path and surface the obvious friction first? rks does that. Like Figma-via-MCP, this is available now and set up ad hoc per session.
Validate — first pass now, polished agent ahead. That first UCD/browser pass is available today. Where it is heading is a polished, automated Visual-QA agent: it would use the model's vision as the "diff engine," so acceptance criteria can be written in plain language instead of pixel comparisons. The first pass is real now; the fully automated visual-QA agent is the direction.
Feed results back as data. The closing move — results flowing back onto the doc that proposed the variant — is the design-through-docs vision above. That closing loop is the one genuinely-VISION piece: direction, not shipped.

Taken together: most of this loop is working today. You prototype fast, wire in Figma through MCP, and take a first browser-driven UCD pass — all real now, just ad hoc to set up rather than one-click. The far end — documentation as the unit of experiment, results flowing back onto the doc — is the vision, and the polished automated visual-QA agent is where validation is heading. The value of naming the whole loop is that each piece is a coherent step toward the same place — testable design — and rks is already built the right way to get there.

7. Knowing what the AI costs

A product owner should not have to guess what AI-assisted work costs. rks makes it visible.

Every governed session tracks token usage, and rks reports it as two numbers, not one:

Raw cost — the total spend across the work.
Waste ratio — how much of that spend went to unproductive work: retries, failed attempts, abandoned stories. It comes with health bands — green under 10%, yellow 10-30%, red over 30%.

The reason for two numbers is a product reason. A single cost figure teaches everyone to optimize that one figure. Two numbers tell a truer story: the same shipped result can cost 58k tokens clean (green) or 199k tokens after failed attempts and retries (red). Same output, very different efficiency — and now you can see which one you got.

Where you see it: in the pull request body when work ships (a permanent per-story record), on demand through a cost report, and in the telemetry surface during a session. For a PM this is ROI made legible — which stories are unexpectedly expensive, whether the system is getting more efficient over time, and where decomposition would pay off.

8. Your role changes — for the better

The last shift is the one that decides whether any of this is usable by a non-engineer. It is.

rks moves the human from directing the tool to supervising and reviewing it. The old model is "modify this function in this file" — instructions only an engineer can give. The rks model is "add a way to reset the display," with acceptance criteria and, if you have them, the files it touches. The agents then plan, build, test, and refine on their own, and surface the result for review.

Your leverage points are exactly the product and design ones:

Define the story — you write the acceptance criteria; the PO step structures them.
Review the gate — architectural review runs a checklist; you weigh in when it blocks.
Review the outcome — you look at the result, the tests, and the cost before it merges.

This is what rks means by optimizing for Agent Experience — the agent is more autonomous so that your attention lands where judgment actually matters. You define the what and review the whether. You stop micromanaging the how. A designer or PM can drive the whole thing through plain-language chat and structured review, without writing code. One honest caveat about today's entry bar: rks currently runs inside VSCode and Claude Code, so getting started does take some technical comfort with those tools — you are working in an editor-based environment, not a standalone app. Lowering that bar is on the roadmap: a friendlier, purpose-built UI for interacting with rks and multi-agent support are under active consideration, so the goal of a non-engineer driving the whole thing end-to-end keeps getting closer.

Safety is guardrails, not walls: risky actions are redirected onto a governed path rather than blocked outright, and everything is logged. You get autonomy where it helps and oversight where it counts.

Coming next

Future posts in this series go deep on single pieces: telemetry and token cost as a product surface, the state machine behind the visible pipeline, and — when it moves from vision toward build — design-through-docs as a testable-design and research surface.

For the architecture behind everything here, read the background architecture post (Part 4 of this series).

Part of the rks blog series.
Background: The Current Architecture (Part 4)