RFCs for Multi-Session Claude Code Work

As a PM, PRDs are my comfort zone - so naturally that’s what I used for all my vibe coding planning. Strategy docs, tech plans, the whole stack. But I kept running into this problem where I’d start a new Claude Code session and have to remind it what’s been done and what hasn’t, or it would retry something I’d already ruled out. I’d been using /compact hoping to bandage this, but that wasn’t solving it either.

When I mentioned this to a vibe dev friend, he pointed me to RFCs - which I’d never heard called that before, but they’re basically detailed tech plans that track execution. The engineers I work with don’t use that term, but the concept clicked immediately. PRDs are for deciding what to build, RFCs are for tracking how you’re building it.

This matters most when the feature implementation is complex, or potentially damaging, or just requires real continuity and rigor across multiple sessions. If Claude needs to pick up exactly where it left off without you babysitting the handoff, you need something that tracks state.

WHAT’S AN RFC RFC stands for “Request for Comments” - it’s how dev teams traditionally propose and track technical decisions. In vibe coding, people call these all kinds of things: implementation-plan.md, progress.md, execution docs, state files. Same idea, different names. The concept shows up in Anthropic’s official best practices, the Plan-Implement-Run pattern, and guides from Zapier and Softr. Your dev friends might call it an RFC, vibe coders might call it a progress doc - it’s the same thing.

WHY PRDS AREN’T ENOUGH

LLMs are stateless - they don’t remember anything between sessions. Every new Claude Code session starts fresh, and without explicit state tracking, Claude will retry approaches you already ruled out, redo steps that are already complete, or start from scratch on something that was halfway done. That’s annoying for simple stuff, but it’s a real problem when the work is complex or potentially destructive - you need Claude to know exactly what’s been tried and what failed before it starts making changes.

Your STRATEGY.md and TECH-PLAN.md tell Claude what you’re building, but they don’t tell it where you left off or what’s already been tried.

WHAT’S STATELESSNESS Stateless means the system doesn’t retain information between interactions - every new session is a blank slate. LLMs don’t “remember” your last conversation unless you give them something to read. More on why this matters for vibe coding.

PRD VS RFC IN AGENTIC CODING

PRD	RFC
What to build + why	How to build + where we are
Static vision document	Living execution document
Written for stakeholder alignment	Written for implementer handoff
Requirements & acceptance criteria	Implementation steps & progress state
Assumes reader will ask questions	Assumes reader has zero context

The RFC becomes your video game save point - it tracks what’s done, what’s in progress, what failed, and exactly where to pick up.

HOW TO PROMPT CLAUDE FOR RFC-BASED PLANNING

Here’s a version of the prompt my vibe dev friend shared with me:

Write the plan first as an RFC, written so any agent with zero context could pick it up and work on it. Track progress, architecture decisions, what's been tried and failed, and any known issues - update all of this in the RFC as you go so the next session can pick it up seamlessly. Include instructions in the RFC itself telling future sessions to read it before continuing work.

The key idea: the RFC isn’t just a plan, it’s a living document that gets updated as you go. Each session reads it, works from it, and updates it before ending.

RFC TEMPLATE FOR MULTI-SESSION VIBE CODING

Here’s a simplified version of the template I use now:

# RFC-001: [Project/Feature Name]

> **Status**: 🟡 In Progress
> **Last Session**: [Date]
> **Next Action**: [What to do first]

## Mission
One paragraph. What we're building and why. This doesn't change.

## Progress Tracker
- [x] Step 1: Set up project structure
- [x] Step 2: Create base components
- [ ] Step 3: Implement auth flow ← CURRENT
- [ ] Step 4: Connect to API

## Last Session Summary
**What Got Done**: Completed steps 1-2, base components working
**What Didn't Work**: Tried Zustand for state, too complex for our needs
**Stopped Because**: Hit token limit mid-auth-flow

## Architecture Decisions
| Decision | Choice | Why |
|----------|--------|-----|
| State management | React Context | Simpler than Zustand for our scale |
| Auth approach | Cookie-based | Avoids JWT complexity |

## Known Issues
- ⚠️ Auth redirect has race condition (see step 3 notes)
- ⚠️ Don't use localStorage in this project (causes hydration issues)

## Session Log
### Session 2 - [Date]
Progress: Completed component library
Next: Start auth flow from step 3

The structure serves specific purposes:

• Progress Tracker at the top - First thing a new session reads
• Last Session Summary - What happened before the session ended
• What Didn’t Work - Prevents re-trying failed approaches
• Architecture Decisions - Append-only log that prevents re-debating
• Known Issues - Landmines the next session shouldn’t step on

HOW TO USE RFCS ACROSS SESSIONS

End of each session:

Update RFC.md:
- Mark completed steps
- Add to "Last Session Summary"
- Note any blockers or failed approaches
- Set "Next Action" at the top

Start of next session:

Read RFC.md and confirm what you understand about current state before proceeding.

Once you get this rhythm going, the RFC basically becomes your handoff document between sessions - Claude reads it and knows exactly where to pick up. You could even automate this with a Claude skill that triggers on “continue” or “pick up where we left off” - but that’s a topic for another post.

WHEN TO USE AN RFC VS JUST A TODO LIST

You don’t abandon PRDs - you layer RFCs on top for complex execution:

Document	When to Use
STRATEGY.md	Vision, audience, principles (write once, reference forever)
TECH-PLAN.md	Architecture decisions, stack choices (write once, update rarely)
RFC.md	Multi-session execution tracking (update every session)

For simple projects - a landing page, a quick feature - you probably don’t need an RFC. STRATEGY.md and a todo list are enough.

For complex projects - anything that’ll take more than 2-3 sessions - the RFC pays for itself the first time you pick up exactly where you left off instead of re-explaining context for 10 minutes.

THE ZERO CONTEXT TEST

A fresh Claude session should be able to:

1. Read the RFC
2. Know exactly what step to work on
3. Know what’s been tried and failed
4. Start working on the next step without asking you to re-explain anything

If a fresh session can’t do all of that from just reading the RFC, you probably need to add more detail to your progress tracking or session summaries.