RDI: Research → Decide → Implement

A deterministic, end-to-end agentic development pattern.

RDI is a system prompting strategy for AI-assisted development that explicitly overrides the default interactive behavior of coding agents. By default, tools like Claude Code work in a collaborative loop: "here's what I found — what do you think?" That suits many workflows. RDI is for when it doesn't — when you want the agent to drive the process end to end, with no approval gates, so long as it stays on the defined path.

The contract is simple: follow the RDI path, and no approvals are needed.

The Pipeline at a Glance

flowchart LR
    P([Problem statement]) --> R
    subgraph R ["🔍 1 · RESEARCH"]
        direction TB
        r1[Web research] --> r2[Trade-off reasoning] --> r3[/Findings/]
    end
    subgraph D ["📋 2 · DECIDE"]
        direction TB
        d1[Document:<br/>findings → dev spec] --> d2[Decide:<br/>commit to approach]
    end
    subgraph SEED ["🌱 Seeding"]
        direction TB
        s1[Plant rdi/ template<br/>into dev repo]
    end
    subgraph I ["🚀 3 · IMPLEMENT"]
        direction TB
        i1[Sprint 01] --> i2[Sprint 02] --> i3[Sprint NN]
    end
    R --> D --> SEED --> I
    I --> DONE([Shipped])

No approval gates between stages — the agent moves through the pipeline autonomously, and the artifacts it leaves behind are the communication.

The Three Phases

1. Research

Gather the evidence needed to inform the best approach to the technical problem. This phase requires:

• Web research — current documentation, comparable implementations, known pitfalls, ecosystem state
• Reasoning — weighing trade-offs between candidate approaches against the problem's actual constraints

The output of Research is a body of findings, not a decision.

2. Decide

Two things happen here — first documentation, then decision:

1. Document — research findings are gathered and consolidated, and a development spec is formulated from them. This spec is what enables spec-driven development downstream.
2. Decide — a concrete approach is selected and committed to.

RDI could equally be framed as Research → Document → Decide → Implement. For simplicity, documentation is folded into the Decide phase.

flowchart TB
    F[/Research findings/] --> DOC
    subgraph DECIDE ["DECIDE phase"]
        direction TB
        DOC["<b>Document</b><br/>Consolidate findings →<br/>formulate development spec"]
        DEC["<b>Decide</b><br/>Select the approach,<br/>state the reasoning"]
        DOC --> DEC
    end
    DEC --> SPEC[("spec.md<br/><i>source of truth</i>")]
    DEC --> N1["decisions/0001<br/><i>root of decision graph</i>"]

The Seeding Step (between Decide and Implement)

Before implementation begins, a template is seeded into the development repository:

• A structure for task management (sprints, task files, status tracking)
• The spec is saved as the source of truth for the project
• The spec is recorded as the first node in a decision graph — every subsequent significant decision is appended, so the project's reasoning is auditable end to end

your-project/
└── rdi/
    ├── STATUS.md                 # current phase + sprint pointer (machine-readable)
    ├── research/
    │   └── findings.md           # consolidated research findings
    ├── spec.md                   # development spec — SOURCE OF TRUTH
    ├── decisions/
    │   └── 0001-adopted-spec.md  # first node of the decision graph
    └── sprints/
        └── sprint-01.md          # task breakdown, first sprint

The decision graph grows as the project does. Deviations from the spec are never silent — they become nodes:

flowchart TD
    n1["0001 · Adopted spec<br/><i>(root node)</i>"]
    n2["0002 · Swapped ORM<br/><i>migration blocker found in sprint 01</i>"]
    n3["0003 · Dropped realtime sync<br/><i>descoped, moved to non-goals</i>"]
    n4["0004 · Auth provider selected<br/><i>closes open risk #2</i>"]
    n1 --> n2 --> n4
    n1 --> n3

The scaffold lives in its own GitHub template repository — danielrosehill/rdi-template — the single source of truth for the seed structure. Seeding is a deterministic clone-and-copy, not a "generate files that look like this" step:

git clone --depth 1 https://github.com/danielrosehill/rdi-template /tmp/rdi-template \
  && cp -r /tmp/rdi-template/rdi ./rdi \
  && rm -rf /tmp/rdi-template

New projects can also be started directly from the template via Use this template or gh repo create my-project --template danielrosehill/rdi-template.

3. Implement

A staggered, sprint-led development approach. Work is broken into sprints derived from the spec. Each sprint has defined tasks; progress is tracked in the seeded structure; deviations from the spec are recorded as new nodes in the decision graph rather than silently absorbed.

Phase Visibility

Because every RDI project carries its phase state in-repo (rdi/STATUS.md), the current phase is machine-readable. This lends itself to UI surfacing — e.g. a status bar showing, for any major project, which phase it's in:

[ RESEARCH ] → [ DECIDE ] → [ IMPLEMENT ]
                  ▲ you are here

Why Deterministic?

Interactive agent workflows optimize for oversight; RDI optimizes for throughput with auditability instead of approvals. The user's control is exercised up front (choosing to invoke RDI, framing the problem) and after the fact (reviewing the spec, the decision graph, and the sprint history) — not through mid-flight check-ins.

Repository Contents

Path	Purpose
system-prompt.md	The RDI system prompt — drop into an agent's system prompt / CLAUDE.md to activate the pattern
claude-code/	Claude Code integration: the /rdi skill, statusline script, and implementation guide
danielrosehill/rdi-template	Companion template repository — the canonical seed scaffold planted between Decide and Implement