How to give Claude Code the context to prioritise your roadmap
A coding agent has read every line you've written and nothing about the world you're selling into. Here's what to hand it so it can argue about priorities, not just implement them.
Why does a coding agent give bad product advice?
Because it has perfect information about your code and none about your market. Claude Code can read every file you've written, so it knows exactly how to build the thing you asked for. It has no way to know whether that thing is worth building — that answer lives in what your competitors already tried, who your customers are, and what you've deliberately ruled out, none of which is in the repository.
So it does the reasonable thing: it takes your framing and executes it well. Ask it to build the wrong feature and you'll get the wrong feature, cleanly implemented, with tests.
The asymmetry nobody names
You've probably noticed your agent is a much better engineer than product thinker, and concluded that's a limitation of the model. Mostly it isn't. It's an input problem.
Think about what each judgment needs. "Is this code correct" is answerable from the code — the agent has everything. "Is this feature worth building" needs the market, the competition, the stage of the company, and what you tried last quarter that failed. The agent has none of it, and nothing about the way it answers signals which situation it's in. It's equally fluent either way, which is exactly what makes it dangerous on the second kind of question.
This is the same failure a new engineer has in their first month, and we handle it correctly with people: we don't ask them to set the roadmap on day one, because we know they lack context rather than intelligence. Then we ask an agent with the same gap and read its confident answer as a considered one.
What to actually put in the file
Four things. Together they're about a page, and the order matters — the agent needs your constraints before the evidence, or it evaluates every option as though all of them are open to you.
- 1
Your hard constraints
Three or four properties that determine what moves are even available: who you sell to, how they find you, how many people you have, what you refuse to do. This is what turns a generic recommendation into a filtered one. Without it the agent optimises for a company with unlimited engineers.
- 2
The companies structurally like you, and what specifically moved for them
Not your category leaderboard — the ones sharing your shape, whatever they sell. For each, the single move and what it changed. This is the evidence base, and it's what lets the agent reason about a proposal instead of recalling best practices about your industry.
- 3
Confidence labels, copied verbatim
If a number came marked stated, estimated or anecdotal, that word must survive into the file. Strip it and every claim reads as equally solid, and the agent will weight a rumour like a filing. This is the single highest-value line of the whole exercise and the easiest to lose in a copy-paste.
- 4
The do-not-build list, with reasons
The territory you've ruled out and whose it is. Agents are relentlessly agreeable about scope — they will help you build anything, including a worse version of a competitor's core product. An explicit exclusion list is the only thing in the file that makes it push back.
- 5
Where the product actually is today
What ships now, what's half-built, what you tried and dropped. Without it you'll get proposals for things you shipped in March, and each one costs you trust in the rest of the answer.
Where to put it so it survives the session
Both major agents read a project file at the root of your repo:
| Agent | File it reads | Note |
|---|---|---|
| Claude Code | CLAUDE.md | Loaded into context at the start of every session in that project |
| Codex | AGENTS.md | Same idea, different filename |
| Both, in one repo | One file, referenced by the other | Two hand-maintained copies drift inside a week, and the one you didn't update is the one that gets read |
Put the market context under its own heading, clearly separated from your build instructions. They're different kinds of statement and mixing them causes a specific problem: engineering conventions are stable, and market facts expire. Keeping them in separate sections is what lets you date the second one and replace it without touching the first.
Date it. A market note written with no date reads as permanent, and in six months it will be quietly steering decisions with facts that stopped being true.
Three things to ask it once the context is there
The point isn't a better implementer — you already had that. It's the three questions an agent couldn't previously take a position on.
Prioritise
"Given the constraints and the twin evidence, which of these five should I do first, and what would have to be true for the answer to change?" The second clause is what makes the answer inspectable.
Shape a roadmap
"Sequence these by funnel step and tell me where the gap is." Agents are good at spotting that you have six acquisition ideas and nothing for the week after signup — once they can see the funnel.
Invalidate
"Argue against the idea I'm most attached to, using the do-not-build list and the evidence, and tell me what would change your mind." This is the one that earns the setup.
The third is the one to build the habit around. Getting an idea killed cheaply, by something holding your own stated constraints, is worth more than a prioritised list you were going to reorder anyway — and it's the only one of the three where the agent's lack of ego is an actual advantage over asking a person.
The mistake: treating the answer as a decision
An agent with good context produces arguments, not verdicts, and the confidence of the prose will not tell you which one you're holding.
Two specific ways it goes wrong. It will treat everything you gave it as equally true, which is why the confidence labels matter so much — an unlabelled anecdote becomes a premise. And it will optimise hard for whatever you told it to optimise for, so if your constraints say "grow signups" it will cheerfully propose something that grows signups and wrecks retention, because you never said retention was in scope.
Both are fixed the same way: make it show the reasoning and name what would change its mind. An argument you can inspect is useful even when it's wrong. A verdict is only useful when it's right, and you can't tell which it is from reading it.
Getting the context without assembling it
Everything above works with research you did yourself, and that's a real afternoon.
It's also most of what a 6to9 report already contains — the companies structurally like you, the specific move each one made and what it moved, per-claim confidence markings, an explicit do-not-build list, and a read of your product as it currently stands. Compressing that into a page for your project file is a copy-paste and an edit.
What ships today, plainly: you assemble that file by hand, and this guide is how. A one-click export shaped for coding agents doesn't exist yet — it's an obvious next step, and we'd rather find out whether founders actually want it than assume. If you would use it, say so on a call and it moves up. That's not a waitlist; it's how we decide what to build next.
What's different a month later
The change is smaller than it sounds and it compounds: one place holding what you know about your market, which every session reads, and which you update when the market moves rather than re-explaining from memory each time.
For the research that fills that file, how to do competitor analysis as a solo founder covers how to choose which companies count as evidence. And for the language half — what to actually say once you've picked what to build — how to find your marketing angle from what's already working is the companion.
Frequently asked
Does this work with Codex, or only Claude Code?
Both, and with any agent that reads a project file. The mechanism is the same — you're supplying market context the agent has no way to obtain — and only the filename differs. Claude Code reads CLAUDE.md from your project root; Codex reads AGENTS.md. If you use both, keep one file and have the other reference it rather than maintaining two copies that will drift within a week.
Why not just paste my competitor research into the chat?
You can, and for a one-off question it's fine. It stops working when the context matters across sessions, because a pasted block is gone the moment the conversation ends and the next session reverts to an agent that only knows the code. Putting it in the project file means every future session starts with it, including the ones where you'd have forgotten it was relevant.
Won't a long context file make the agent worse?
It will if you paste a whole report in. What earns its place is the compressed version — your constraints, the handful of companies structurally like you and what specifically moved for them, what you've decided not to build, and where the product currently is. That's a page or so. The full report is a thing you reference when a specific question comes up, not something that should sit in every prompt.
Isn't asking an AI to prioritise just outsourcing the judgment?
It would be if you took the answer. The use that actually pays is adversarial — you decide, then ask it to argue the other side using the evidence you gave it. An agent holding your do-not-build list and your twin evidence is genuinely good at spotting that your favourite idea is on ground a bigger competitor owns. It is not good at knowing how much you care.
What stops it from confidently making things up about my market?
Mostly, giving it real material to work from instead of asking it to recall. The other half is preserving the confidence labels when you paste — if the source marked a number as anecdotal, that word has to survive the copy, or the agent will treat it exactly like a verified one. Stripped labels are how a soft claim becomes a hard input.
Do I need a 6to9 report to do this?
No. The structure in this guide works with research you did yourself, and the section on what to include is deliberately written to be usable that way. What the report saves you is the assembling — it arrives already shaped as constraints, twin evidence with confidence markings, and a do-not-build list, which is most of what the file needs.
Published August 27, 2026
Want this as one button instead of a copy-paste?
Today you assemble the context yourself, and this guide is how. A one-click export shaped for coding agents is something we're weighing — if you'd use it, we'd rather hear that from you than guess.
New to 6to9? See how it works in four steps.