DEV Community: Diogo Soares

Spec Before Code: How OpenSpec Keeps AI Coding Agents Building the Right Thing

Diogo Soares — Fri, 16 Oct 2026 16:02:42 +0000

Over the past few months I've changed a lot about how I work with coding agents, and one of the tools that made the biggest difference was OpenSpec.

The problem it solves is simple. When you ask an AI for something straight in the chat, the requirement only exists in that conversation. The agent reads it its own way, and you often find out it misunderstood after 400 lines of code. Close the session and the context is gone with it.

OpenSpec flips the order: before any code gets written, you and the agent agree on what will be built, in writing, inside the repository.

This post covers how OpenSpec is organized, what the workflow looks like with a concrete example, when it's worth the extra step, a weakness in the verification step that came up in a great discussion on LinkedIn, and how it relates to ADRs.

What OpenSpec is

OpenSpec is an open source (MIT), lightweight framework for spec-driven development with AI coding assistants. It works with Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, OpenCode and 30+ other tools, through slash commands the agent understands.

It isn't a new IDE or a platform you have to move to. It's a folder of Markdown files in your repository, a small CLI, and a set of instructions for your agent.

Installing it takes two commands:

npm install -g @fission-ai/openspec@latest
cd your-project
openspec init

openspec init asks which tools you use and installs the matching commands and instructions for each of them.

How it's organized

Everything lives in an openspec/ folder, split in two:

openspec/
├── specs/                  # Source of truth: how the system behaves today
│   ├── auth/
│   │   └── spec.md
│   └── payments/
│       └── spec.md
└── changes/                # Proposed modifications, one folder each
    ├── add-password-reset/
    │   ├── proposal.md     # Why and what
    │   ├── design.md       # How (technical approach)
    │   ├── tasks.md        # Implementation checklist
    │   └── specs/
    │       └── auth/
    │           └── spec.md # Delta: what changes in auth
    └── archive/            # Finished changes, kept for history

specs/ describes how the system currently behaves, organized by domain.
changes/ holds proposed modifications. Each change is a self-contained folder, so two changes can be in progress at the same time without stepping on each other.

The key idea is the delta spec. A change doesn't restate the whole spec. It only describes what is being added, modified or removed. That makes OpenSpec work well on existing codebases, which is where most of our work actually happens.

The workflow

In practice, the flow looks like this:

Explore (/opsx:explore): the agent reads the codebase and helps you understand the problem and the options. No code, no commitment.
Propose (/opsx:propose <name>): it drafts the change folder: proposal, delta specs, design and tasks.
You review it. This is the most important step. Fixing a paragraph is far cheaper than fixing a pull request.
Apply (/opsx:apply): the agent implements the tasks, checking them off as it goes.
Verify (/opsx:verify): it checks that the implementation matches the spec. This one is part of the expanded workflow profile, which you enable with openspec config profile.
Archive (/opsx:archive): the deltas are merged into specs/, and the change folder moves to changes/archive/ with a date prefix.

After archiving, the spec describes the system as it is now, and the archived change keeps the full story of why it got that way.

The steps aren't rigid gates. You can go back and update the proposal or the design at any point when you learn something during implementation. That flexibility is one of the things I like most about it compared with heavier spec frameworks.

A concrete example: password reset

Say you want users to reset their password by email, with a link that expires in 15 minutes. Here's what the main artifacts look like.

proposal.md captures the intent and, just as important, the scope:

# Proposal: Add password reset by email

## Intent
Users who forget their password currently need to contact support.
Let them reset it themselves with a secure, short-lived link.

## Scope
In scope:
- "Forgot password" request from the login screen
- Single-use reset link sent by email, valid for 15 minutes
- Revoking active sessions after a successful reset

Out of scope:
- SMS or authenticator-based recovery
- Changes to the sign-up flow

The delta spec describes observable behavior with concrete scenarios:

# Delta for Auth

## ADDED Requirements

### Requirement: Password reset by email
The system MUST let a user reset their password through a single-use
link sent to their registered email, valid for 15 minutes.

#### Scenario: Valid reset link
- GIVEN a user requested a password reset 5 minutes ago
- WHEN they open the link and submit a new valid password
- THEN the password is updated
- AND all of the user's active sessions are revoked
- AND the link can no longer be used

#### Scenario: Expired link
- GIVEN a reset link created 16 minutes ago
- WHEN the user opens it
- THEN the reset is refused with a "link expired" message
- AND the password is unchanged

#### Scenario: Unknown email
- GIVEN no account exists for the submitted email
- WHEN a reset is requested
- THEN the response is identical to the one for an existing account
- AND no email is sent

That last scenario is a good example of why the review step matters. "Don't reveal whether an account exists" is easy to forget in a prompt, and it's a security requirement. Written as a scenario, it's visible, reviewable and testable.

design.md holds the technical approach (how tokens are generated and stored, rate limiting, which email service), and tasks.md is the checklist the agent follows during Apply:

## 1. Reset tokens
- [ ] 1.1 Generate single-use tokens with a CSPRNG; store only their hash
- [ ] 1.2 Expire tokens after 15 minutes; invalidate on use
- [ ] 1.3 Tests for valid, expired and reused tokens

## 2. API
- [ ] 2.1 POST /password-reset/request with identical responses for unknown emails
- [ ] 2.2 POST /password-reset/confirm; revoke sessions on success
- [ ] 2.3 Rate limit both endpoints per IP and per account

The spec says what the system must do. The design and tasks say how. Keeping those apart is what lets you review the behavior without getting lost in implementation details.

What to look for when you review

Since the review is the step that pays for everything else, it's worth being deliberate about it. These are the questions I ask:

Is the scope right? Is anything in scope that shouldn't be, or missing from the out-of-scope list?
Are the scenarios concrete? "The link expires" is vague. "A link created 16 minutes ago is refused" is testable.
Are the edge cases there? Errors, empty states, abuse, permissions, concurrency.
Does anything conflict with existing decisions? A new library, a new pattern, a different way of storing data.
Could someone write a test from each scenario? If not, it's still too ambiguous.

When it's worth using

Features that touch several parts of the system. The more the work spreads across the codebase, the more expensive a late misunderstanding gets.
Existing codebases. The agent needs to understand what's already there before changing it, and delta specs are designed for exactly that.
Teams with more than one person (or more than one agent) on the same code. Everyone works from the same document, not from different chat histories.
Requirements that are still moving. Updating the spec and regenerating the tasks is easier than rewriting code.

And when it isn't: one-line bug fixes, small visual tweaks, throwaway scripts. There, the process gets in the way more than it helps. OpenSpec's own docs push in the same direction: most changes should use a light spec, and the full treatment is for higher-risk work like API contracts, migrations and security changes.

My rule of thumb: if I'd have to explain the task to a teammate before they started, it deserves a spec.

The Verify trap: who checks the checker?

When I posted about OpenSpec on LinkedIn, someone asked a question I think every team using spec-driven development should think about:

If the same agent that implemented the tasks also verifies the implementation against the spec, what stops it from misreading the spec the same way in both steps?

The concern is real. If the same agent, with the same context, implements and then verifies, it tends to repeat the same misreading. The Verify step is good at catching what was left out or not done. It doesn't guarantee the interpretation was right in the first place.

What you can do to reduce that risk:

Make the scenarios concrete. The more specific they are, with real input and output values, the less room there is for interpretation. The spec review is the moment to remove ambiguity.
Turn the scenarios into tests before Apply. Essentially acceptance tests, written by a person or by a separate agent, based on the spec and not on the implementation. Each GIVEN/WHEN/THEN maps naturally to a test.
Keep those tests hidden from the implementing agent. Run them only in CI, or block read access to that folder in the agent's permissions. Like a held-out evaluation set, this stops the agent from writing code just to make the tests pass.
Verify in a clean session, with no history from the implementation. Using a different model can help too. OpenSpec's own docs recommend clearing the context before implementation, and the same hygiene applies to verification.
Let CI have the final word. The tests running in the pipeline decide, not the agent saying everything matches.

The discussion went one step further: if someone outside the team, like a customer or an auditor, doubted a green run, how would they know the hidden tests weren't edited after the code was written, and that they ran against that exact build? The short answer involves locking the tests before Apply, pinning their commit in CI, and signed build provenance (SLSA, Sigstore). It's a big enough topic that I'll cover it in a separate post.

OpenSpec and ADRs

A question I get often: if I already write ADRs, do I need specs? They solve different problems and work well together.

	ADR	OpenSpec
Answers	Why did we decide this?	What should the system do?
Unit	One decision	One change or capability
Lifecycle	Immutable; superseded by a new ADR	Living; updated with every archived change
Leads to implementation?	No	Yes: tasks, apply, verify
Horizon	Long term, history	The current change and the current state

They meet in design.md. A change's design often contains technical decisions. If a decision only matters for that feature, it can stay there. If it goes beyond the feature and affects the whole project (switching databases, changing the authentication approach, adopting a queue), write an ADR and link it from the design.

A practical rule: if someone will want to know in two years why something was done this way, write an ADR. If you want the agent to build the right thing now, write a spec.

I wrote more about ADRs and AI agents in ADRs Are the Guardrails Your AI Coding Agent Is Missing.

Getting started

Install the CLI and run openspec init in an existing project.
Pick a real feature of medium size, not a one-line fix and not a rewrite.
Start with /opsx:explore and let the agent map the code before proposing anything.
Run /opsx:propose, then spend real time on the review. Rewrite vague scenarios until each one could become a test.
Apply, verify, archive, and look at how specs/ changed.

After one or two changes, you'll have a feel for which work deserves a spec and which doesn't.

Conclusion

AI agents are very good at building what you asked for. The hard part is making sure what you asked for is what you actually meant. OpenSpec moves that agreement out of a chat window and into the repository, where both people and agents can read it, review it, and come back to it later.

It isn't magic, and the verification step needs help from good tests to be trustworthy. But writing the spec before the code is one of the habits that improved my work with agents the most.

How about you? Do you write the spec before asking the AI for code, or do you still go straight to the prompt?

From One Prompt to Every Screen: Claude Code's Editable Design Canvas

Diogo Soares — Fri, 16 Oct 2026 15:54:52 +0000

Every new product or feature starts the same way. Before anyone can discuss the idea, someone has to draw the obvious: login, home, a list, a detail page, a profile. Then the states nobody draws in the first version: empty, loading, error, success.

It's necessary work, but it's not where design adds the most value. The valuable part comes after: flow, hierarchy, interactions and product decisions.

A recent Claude Code feature goes straight at that bottleneck. You can ask, in plain language, for every screen of your app, and you get back a design canvas where each screen is a live, editable artboard. Not a screenshot. Not a static mockup.

This post covers what it is, what happens under the hood, how to ask for it, and the tips that make the difference between a generic result and a useful first draft.

What it is

The result is an infinite canvas with live artboards. Each screen becomes a frame on the canvas, at real device size, organized by flow, with titles and notes.

It isn't limited to mobile apps. The same canvas works for web pages, landing pages, and even social media posts.

The canvas is published as a private page on claude.ai. You see the screens appear as they're drawn, and you decide whether and when to share it with your team.

How to ask

There's no special command or syntax. You just ask. It works anywhere Claude Code runs: the terminal, the desktop app or the web.

A good first request looks like this:

Create a design canvas with every screen of the app in this repo:
onboarding, login, home, calendar, detail and profile.
Mobile 390×844. Include empty, loading and error states.
Use our design system.

The most useful detail: run it inside your repository. Claude Code reads the code to find the screens that actually exist (routes, pages, components), so the canvas reflects your real app instead of a generic template.

What happens after you hit Enter

Roughly four steps:

It understands the request. It reads the repo, its routes and components, to learn which screens exist and how they connect.
It picks the look. If your account or organization has a default design system, it uses it. If not, it defines a coherent visual identity and tells you which decisions it made.
It draws screen by screen. Each artboard is an independent HTML component at real device size, which is why everything stays editable.
It hands you the link. A private canvas on claude.ai, where you watch the screens appear and decide what to do next.

The part that won me over: everything is editable

This is what separates it from "AI generated a picture of an app".

Because every screen is a live component, you can:

Tweak it directly. Change copy, colors and spacing in a properties panel, and see the screen update right away.
Comment on a screen. Leave a comment like "make the card bigger and swap the icon", and Claude makes the change on that screen.
Keep iterating in conversation. Ask for a new variation, a new state or a new flow without starting over.
Take it further. Link screens into a clickable prototype, or share the canvas with your team for feedback.

Five tips for a great canvas on the first try

The quality of the canvas depends a lot on the quality of the request. These are the things that matter most.

1. Name the screens and flows

"Design my app" gets you something generic. Name each screen and group them into flows: onboarding (welcome, sign up, permissions), auth (login, password reset), main (home, list, detail, profile, settings).

2. Set the format

Say what you're designing for: mobile at 390×844, web at 1440px, a landing page, a social post. Otherwise you'll get a reasonable guess, which may not be your guess.

3. Ask for the states

Empty, loading, error and success. This is where most of the time savings are, because these are the screens nobody wants to draw by hand, and the ones most often forgotten until development.

4. Point to the brand

Your design system, colors, fonts, or simply the repository. Without a reference, it will create a coherent identity, but it won't be yours.

5. Iterate in small steps

"On the login screen, change the CTA to 'Continue with email'" works much better than asking it to redo everything. Small, specific requests keep what's already good and change only what you asked for.

A full prompt you can copy

Putting the tips together, this is a prompt I'd use as a starting point:

Create a design canvas with every screen of the app in this repo.

Flows:
- Onboarding: welcome, sign up, permissions
- Auth: login, password reset
- Main: home, list, detail, profile, settings

Mobile 390×844, one artboard per screen, grouped by flow with a title for each.
For each main screen, also include the empty, loading, error and success states.

Use our design system. If there isn't one, propose a simple identity
and tell me which decisions you made.

Use real copy from the app's domain, no lorem ipsum.

The last line matters more than it looks. Real copy makes layout problems visible early: long names, button labels that don't fit, empty states that need an explanation.

What it doesn't do

It's worth being clear about the limits, so expectations stay realistic:

It doesn't replace designers. It gives you a starting point. Decisions about hierarchy, interaction, accessibility and the product itself are still human work, and they're the ones that matter most.
Vague requests give generic results. If you don't name screens, formats and states, you get a plausible but bland app.
It reflects what it can read. If the repo is half-built or the screens are only in someone's head, describe them in the prompt.
Review it like any first draft. Check contrast, touch target sizes and edge cases before treating anything as final.

Who it's for

Designers skip the rough draft and start at refinement: hierarchy, interactions and product calls.
Engineers see the screen before coding, and can discuss layout and states with something concrete instead of a description in a ticket.
Product managers validate a flow early, bringing real screens into the conversation before the sprint starts.

The way I see it: designers keep making the calls. Claude delivers the starting point.

Wrapping up

The time between "we have an idea" and "we have screens to discuss" used to be measured in days. With an editable canvas generated from your own repository, it can be minutes, and what you get is something you can keep working on, not a picture you have to redraw.

If you try it, start small: one flow, one format, all the states. Then iterate.

Have you tried it yet? I'm curious how designers feel about starting from a generated first draft instead of a blank canvas.

ADRs Are the Guardrails Your AI Coding Agent Is Missing

Diogo Soares — Fri, 16 Oct 2026 15:21:31 +0000

If you work with AI coding agents every day, you have probably seen this: you ask for a small change, and the agent suggests swapping your authentication library, changing your data access pattern, or "simplifying" something that was built that way for a good reason.

The agent isn't doing this on purpose. It just doesn't know why your decisions were made.

I've been using Architecture Decision Records (ADRs) for years as a team practice. Since AI agents became part of my daily work, they stopped being "nice documentation" and became one of the most effective guardrails I have. This post explains why, shows a real example from one of my projects, and describes how I turn ADRs into guardrails that an agent actually follows.

Why agents keep reopening settled decisions

An agent like Claude Code, Cursor or Copilot knows a lot about software in general and very little about your project in particular. Three things make this worse than it sounds:

No memory between sessions. Every session starts from zero. The agent only knows what is in its context: your prompt, the files it reads, and the instruction files you give it.
Code shows the "what", never the "why". The agent can see that you use PostgreSQL. It cannot see that you evaluated MongoDB, rejected it because of reporting needs, and accepted the extra migration work on purpose.
Without constraints, it falls back to generic best practices. If nothing says otherwise, the agent will optimize for what is usually a good idea, not for what is right in your context. Those are often not the same thing.

That "why" used to live in the heads of the people who had been on the team the longest. A new developer would ask, and someone would explain. An agent doesn't ask. It acts on what it can read. If the reasoning isn't written down, from the agent's point of view it doesn't exist.

What an ADR is

An ADR is a short document that records one architectural decision. It is not a design doc and it is not a wiki page that tries to describe the whole system. It captures a single decision at a single point in time.

A good ADR answers four questions:

Context: what problem did we have, and what constraints were we under?
Decision: what did we choose?
Alternatives: what did we reject, and why?
Consequences: what did we gain, and what did we give up?

This is the template I use. It is intentionally small:

# NNNN. Title

- **Status:** Proposed | Accepted | Superseded by NNNN
- **Date:** YYYY-MM-DD

## Context

What forces are at play (product goals, technical constraints, costs)?

## Decision

What we decided, stated in full sentences ("We will…").

## Consequences

What becomes easier or harder, the risks we accept, and the follow-ups this creates.

ADRs live in the repository, usually in docs/adr/, numbered in order, with an index in docs/adr/README.md. Two rules make them work over time:

An accepted ADR is never rewritten. If the decision changes, you write a new ADR that supersedes the old one.
Each ADR has a status. Readers (human or not) can tell which decisions are still in force.

A real example: when a decision has to change

I'm building a personal running app (React Native with Expo, a Node API, Strava integration). It has 32 ADRs so far. Here is a pair that shows why this matters with agents.

ADR 0004 says: the app does not record GPS. Strava is the single source of recorded activities. The reasoning is in the context section: the watch and Strava already record runs well, background GPS isn't available in Expo Go, and duplicating recordings would only add battery drain and complexity.

Without that ADR, an agent asked to "show the distance of each interval" would very likely add GPS recording. It is the obvious solution, and it would quietly break a decision I made on purpose.

Then a real need appeared. During track workouts with timed reps (for example, 10 × 30 seconds), I don't know how far I ran in each rep, and my coach asks for it. That is a different problem: I don't need a recorded activity, only the distance inside each fast window.

So I didn't "just add GPS". I wrote ADR 0020, which partly supersedes ADR 0004, for timed reps only. It records:

the constraint: in Expo Go, location updates only arrive while the app is in the foreground;
the decision: GPS is watched during sessions with timed reps, noisy fixes are filtered out, and only the metres per rep are kept, with no stored or uploaded positions;
the consequences: a few metres of error per rep, extra battery use, and the screen must stay on. Measuring with the screen locked would need a development build and a new ADR.

The important part is the last line of that ADR: Strava stays the source of recorded activities (the rest of ADR 0004 holds).

Now, when an agent works on this code, it can read exactly where the line is. GPS is allowed for timed reps, under specific rules. It is still not allowed for recording runs. And if I ever ask for something that crosses that line, the agent has what it needs to stop and tell me: "this conflicts with ADR 0004 and ADR 0020".

That is the shift. The agent stops being something that might break your decisions and becomes something that can defend them.

From documentation to guardrails

Writing ADRs is the first step, but an ADR sitting in a folder is only useful if the agent reads it. Over time I ended up with four layers. Each one covers a weakness of the previous one.

Layer 1: ADRs hold the "why"

The ADRs are the source of truth for decisions and their reasoning. Everything else points to them.

Layer 2: the instruction file turns decisions into rules

Agents read an instruction file at the start of every session (CLAUDE.md, AGENTS.md, .cursor/rules, copilot-instructions.md, depending on the tool). This is where ADRs become short, explicit rules, each one citing the ADR that explains it.

Here is part of the CLAUDE.md from the running app:

Read `README.md` and `docs/adr/` before changing architecture.

## Rules

1. Every project decision becomes an ADR in `docs/adr/` (template there;
   never rewrite an accepted ADR, supersede it). Update the index in
   `docs/adr/README.md`.
2. `packages/domain` is framework-free: no React, Expo, Node or HTTP imports.
3. Mobile runs in Expo Go. Anything that needs a dev build (Face ID,
   HealthKit, background GPS) requires an ADR first.
5. Strava is the activity source; never record activities with GPS (ADR 0004).
   GPS only measures timed reps (ADR 0020).
7. Tokens only in secure storage; never in AsyncStorage/SQLite/logs (ADR 0005).

A few things make this work:

The rule is short; the reasoning is in the ADR. The instruction file stays small enough that the agent reads all of it every time, and it can open the ADR when it needs the details.
Each rule cites its ADR. When the agent pushes back, it can say which decision is at stake, and I can check whether that decision still makes sense.
Some rules are gates, not prohibitions. "Requires an ADR first" doesn't forbid background GPS forever. It forces the conversation to happen before the code, which is exactly when I want to have it.

Layer 3: the process makes the agent part of the ADR workflow

Agents are good at writing ADRs. They are fast at summarizing context, listing alternatives and spelling out consequences. So I let them draft, and I decide.

My workflow looks like this:

Before any structural change, the agent reads the relevant ADRs.
If my request conflicts with an accepted ADR, the agent says so and names it, instead of silently working around it.
If the decision really needs to change, the agent drafts a new ADR (status Proposed) that supersedes the old one, and updates the index.
I review it, change what's wrong, and only then mark it Accepted and implement.

This keeps a human in charge of the decisions while the agent does most of the writing. It also means the history is never lost: six months later, both I and the agent can follow the chain from ADR 0004 to ADR 0020 and understand why the code looks the way it does.

Layer 4: automated checks enforce what can't be left to reading

Instruction files are strong guidance, not guarantees. Agents follow them most of the time, but not always, especially in long sessions or when the context gets crowded. So for decisions where a violation would be expensive, I don't rely only on the agent reading a rule. I make the build fail.

Some examples of decisions that can be enforced automatically:

Layer boundaries: a lint rule (for example, no-restricted-imports in ESLint, or a dependency-cruiser config) that blocks framework imports inside the domain package.
Security decisions: in the running app, the API's security decisions are in an ADR, and a smoke test against the production image runs the matching attack checks: user enumeration, 2FA bypass, mass assignment, a tampered JWT, deleting another user's data (IDOR), refresh-token replay. If an agent "simplifies" the authorization logic, the check fails.
Domain rules: unit tests that encode the rules an ADR describes, such as how GPS fixes are filtered.
Agent hooks: many tools now support hooks that run before or after the agent edits files or runs commands. They are a good place for fast checks, like blocking edits to accepted ADRs or running the linter after every change.
A single "done" command: one command (npm run check in my case) that runs lint, type checks and tests, which the instruction file requires before a task is considered done.

A simple way to think about the layers:

Layer	What it does	Its weakness
ADR	Explains why a decision was made	Only works if someone reads it
Instruction file	Turns decisions into rules the agent reads every session	Guidance, not enforcement
Process	Forces decisions to be discussed before code is written	Depends on discipline
Automated checks	Fails the build when a decision is violated	Only covers what can be checked

None of these layers is enough on its own. Together, they cover each other's gaps. The ADR is what ties them together: every rule, gate and check can point back to a decision with a written reason.

What not to do

A few mistakes I've made or seen:

Writing ADRs for everything. Naming a variable is not an architectural decision. If reverting the decision would be cheap, it probably doesn't need an ADR.
Writing long ADRs. If an ADR needs ten pages, it is a design doc. Agents and humans both skip long documents. One or two screens is usually enough.
Editing accepted ADRs. It feels faster, but you lose the history, and the agent loses the ability to understand how and why things changed.
Leaving superseded ADRs without a status. Two ADRs that contradict each other, both marked Accepted, will confuse an agent more than having no ADRs at all.
Not linking ADRs from the instruction file. If the agent doesn't know the folder exists, it might never open it.

Getting started in an afternoon

If your project has no ADRs yet, you don't need to document its entire history. Start small:

Create docs/adr/ with a template and a README index.
Write ADR 0001: "We record architecture decisions using ADRs".
Write ADRs for the three to five decisions an agent (or a new developer) is most likely to undo: your data store, your authentication approach, your layering rules, and anything that looks "wrong" but is intentional.
Add a short rules section to your agent's instruction file, with each rule pointing to its ADR, plus the instruction to read docs/adr/ before structural changes.
Pick the one decision that would hurt most if broken and add an automated check for it.

From then on, every new decision gets an ADR, and you can ask the agent to draft it.

Conclusion

Documenting decisions has always been good practice. The difference now is who reads them. With AI agents on the team, your ADRs are read every day, by a reader that has no memory, never asks "why", and will happily change anything that isn't explained.

Write the "why" down, turn it into rules, and enforce what matters most. That's what makes an agent's work fit your project instead of a generic idea of what a project should look like.

Do you use ADRs in your projects? How do you give that context to your agents? I'd like to hear what has worked for you.