The Source-of-Truth PRD Cascade
Spend a day writing five layered docs so the agent, not you, carries the context on every build.
- Difficulty
- Moderate
- Time to result
- ~days to results
- Steps
- 6
- Confidence
- 92%
Once you've picked a direction, resist building and instead author a cascade of markdown documents that become the agent's permanent context: a high-level master plan, an implementation plan, design guidelines, user journeys, and finally a tasks.md — all governed by a rules file. Because an LLM's context window is finite and forgets early messages, these docs let you delegate context to the agent so your prompts shrink to 'proceed with the next task' and you can run multiple projects at once.
Origin
Lazar Jovanovic's own system, built to work around the token/context-window limitation he explains via an Aladdin-and-the-genie analogy (the genie grants only three wishes at a time = the model can only hold so much context per request).
Core principles
- 01Coding is a solved problem; the real bottleneck is clarity and context, so optimize time toward planning: '80% of my time in planning and chatting and only 20% in executing the plan.'
- 02The context window is a scarce, finite resource ('three wishes, not 3,000') — spend it on thinking and executing, not on the agent re-reading an undocumented codebase.
- 03All the upstream docs exist in service of one file: tasks.md, the executable list of tasks and subtasks.
- 04AI reads markdown best, so write the source-of-truth docs in markdown.
- 05Make context dynamic: update the docs over time so you deliberately shift what the token window holds as the project evolves.
- 06Once docs and rules are in place, stop prompting for context — your prompts become 'proceed with the next task.'
How to run it
- 1
Write the master plan
A 10,000-foot document stating the intent: why you're building this, who it's for, and how you want them to feel. It references the other docs (e.g. 'consult design-guidelines.md for exact parameters').
- 2
Write the implementation plan
A higher-level ordering of how to build it — e.g. start with the backend and tables, then authentication, then the API. It sets sequence, not nitty-gritty detail.
Pro tip Think of it as a technical co-founder sketching the road map after hearing your idea — order of things, not RFCs.
- 3
Write design guidelines
Define how the app should look and feel, including some CSS-level specifics, because AI is 'sometimes over creative' with design and needs technical steering.
Pro tip Because the model isn't emotionally intelligent yet, be more prescriptive here than anywhere else — pin down fonts, styles, and gradients explicitly.
- 4
Write the user journeys
Describe, high level, how a user navigates: they register, then what's the second step, the third step, and the key features they touch along the way.
- 5
Compile tasks.md
Feed the four upstream docs in and generate the concrete list of tasks and subtasks the agent will execute to reach the finish line. This is the operational source of truth.
- 6
Set the rules/agent file
In rules.md or the tool's project-knowledge settings, tell the agent how to behave: read all the PRDs first, check tasks.md for the next task, execute it, then report what it did and how to test it — so you never repeat yourself per prompt.
Pro tip End the instruction with 'when you're done tell me what you did and how I should test it' so you can verify by reading the agent output, not the code.
Watch out Skip this and, once something breaks, the agent will read your entire undocumented codebase to orient — burning ~80% of the token allocation on reading and leaving almost nothing for the actual fix.
In the wild
Lazar describes building a project with 60-70 edge functions. Without reference docs, telling the tool 'this broke' forces it to read every function to find which does what, consuming most of the token budget before it can think.
→ With the PRD cascade and rules in place, he points the agent at the relevant file instead, preserving the scarce token budget for actually diagnosing and fixing the issue.
After loading the agent with all docs, rules, and tasks, Lazar stops prompting mid-flow — his prompts reduce to 'proceed with the next task' while he switches between tabs.
→ He can build five projects simultaneously without losing productivity, because context lives in the documents rather than in his active attention.
Common mistakes
Vibing your way through a real build with no documentation
Prototyping by pure vibes is fine for exploration, but on a project meant to last it means when something breaks there are no reference points, the agent must read everything, and it exhausts the token window before it can fix anything.
Optimizing for execution speed instead of planning speed
Most people rush to build and under-invest in planning. Lazar spends 80% of his time planning and chatting and only 20% executing — 'most people optimize for the wrong one.' Skipping the planning collapses quality downstream.
Is it for you?
Best for
Anyone moving from prototype to a durable, production-grade build in tools like Lovable, Cursor, or Claude Code who needs the work to scale and survive debugging.
Not ideal for
Quick throwaway prototypes and exploration, where the documentation overhead outweighs a 30-minute demo you'll discard.
From the transcript
“I spent 80% of my time in planning and chatting and only 20% in executing the plan”
“I usually build something that I call a master plan it's basically a compass saying here's what we're building”
“I've learned that AI likes to read markdown”
“you're letting the agent know how you want it to behave and what it should focus on in the long run so that you don't…”
From the episode
The rise of the professional vibe coder (a new AI-era job)
Lazar Jovanovic (Professional Vibe Coder)