What you end this module with
You end this module with a brief Claude can build from: every fact confirmed, every assumption marked as one, every gap named instead of quietly filled in.
The course follows Tool Scout: a fictional product team comparing five AI app builders for its next prototype. The files and review findings are adapted from a worked build; the business context and conversations have been rewritten for teaching.
What this module teaches
Six ideas, in the order they matter. The context window explanation carries into every later module: see The Operating Brain for what the same idea looks like at company scale, not session scale.
- The harness: you, the controls, the engine
Claude Code is three things working together, not one. You hold the intent: what actually needs to exist. The engine is the model doing the reading, writing and reasoning. The controls sit between you and it: permissions, hooks, which tools it can touch. A vague ask skips straight to the engine and leaves the controls with nothing to steer. - The context window as working memory
Think of the context window as RAM, not as a chat log. It fills with your system prompt, loaded skills, memory files and the conversation itself. Most of what's in there, you never typed. At 60–70% full, responses start dropping detail and quietly forgetting earlier decisions. That's the moment to compact or hand off, not the moment it visibly breaks. - The three inputs: skills, context, raw data
Every answer Claude gives is built from three kinds of input, and it's worth knowing which one is missing when an answer is wrong. Skills are the how: a written method it can load and follow. Context is the what's-already-true: your brief, your CLAUDE.md, your prior decisions. Raw data is the facts for this specific task. A vague brief starves all three at once: no method named, nothing agreed yet, no facts supplied. - Prompting in order, the six steps
Order is the lesson, not the individual prompts. Context first, so it's not guessing what matters. A play-back, so you catch a misread before it compounds. A direct question about what data would remove its guesses. Then it asks you back, one question at a time, until it's 95% sure. Then a range of options, not one plan. Then a deliberate challenge to its own answer. Skip a step and the ones after it inherit the gap. - Asking before building
The fourth of the six steps, and the one most tempting to skip. A question costs a sentence. A build on a wrong assumption costs the afternoon, and you don't find out which assumption was wrong until you're looking at the wrong thing. Telling Claude explicitly not to assume, and to ask one question at a time, is what turns a one-paragraph idea into a brief with no silent gaps. - Challenging what comes back
The sixth step, and the one that catches what agreement alone won't. Once a plan is agreed, asking Claude to argue against its own answer (using an evidence-led skill, not a vague "any concerns?") surfaces defects a friendly read-through misses. On Tool Scout this step alone found two launch-blocking defects and five operational risks before a line of code existed.
The assignment
Starts from
An empty folder and a deliberately vague one-paragraph brief for your project. (The reference project's version, Tool Scout, is below.)
Required output
docs/brief.md: confirmed facts, explicit gaps marked as gaps, agreed success criteria.
Passes when
The brief separates what is known from what is assumed, and every assumption has either a source or an open question against it. Nothing is silently filled in.
Here is the brief Tool Scout actually started from: one paragraph, no structure, exactly what a real idea sounds like before anyone questions it.
Our product team is choosing an AI app builder for its next prototype. I want a simple page we can open during a planning meeting to compare the main tools. It should be quick to keep up to date and something we can actually trust.The six Claude Code prompts, in order
Order is the lesson, not any single prompt. Copy them in sequence against your own brief.
Use the <skill> skill. Read docs/brief.md and dev-docs/pt1-<name>.md first.Points at the skill and the files that matter before any work starts.
Summarise the brief, the problem and where the work stands today.If the play-back is off, you are not on the same page yet.
What data can I give you that removes every assumption you are making, so you answer me with facts only?Where it has no data, it fills the gap with a plausible guess. Ask what would replace the guesses.
Ask me questions, one at a time, until you are 95% confident you understand exactly what I need. Do not make assumptions.Questions are cheap; a build on a wrong assumption costs the afternoon.
How can we <problem>? Three options: a fix for today, a bigger fix that still hurts, and the proper one. Two short paragraphs each.Naming the range stops it jumping to the full rebuild. Now, next and later, side by side.
Play devil's advocate on this. Where does it break?No flaw found? Ask for a new plan from the original brief, keep both, hand them to a fresh agent.
What the conversation looked like
Three adapted exchanges from step 4, one question at a time, using the fictional team’s brief.
Owner
1. We haven't interviewed the team about its requirements yet. That's a gap, mark it as one.
2 and 3. Leave a final recommendation out for now. Version one compares the five tools only...
Ask me questions, one at a time, until you are 95% confident you understand exactly what I need. Do not make assumptions.
Claude
Saved your answers. Missing requirements interviews are marked as a gap.
Question 1: What kind of prototype does the team want to build? For example: a marketing website, a customer app, an internal dashboard, or something else?Owner
Four points, no more: 1. Cost for a small team... 2. Real app parts... 3. Leaving... 4. Security and data...
Claude
Saved: four points, with security and data done last.
Question 3: What counts as a trusted source?
A. Tool's own site only
B. A + third parties (reviews, forums, YouTube tests)
C. A + our own hands-on test
Which one: A, B or C?Owner
Yes, data.js.
Claude
I'm now at 95%. Here's what you need, in one line:
One internal web page that compares Lovable, Bolt.new, v0, Replit and Figma Make on 4 points. It uses only each tool's own pages, with a link, a date and "Not stated" where they say nothing. The facts live in data.js, which the product lead re-checks by hand every month.
Did I get it right, and should I start with step 1?The project at this point
Same file, before the six prompts and after. Adapted for this example and shortened for readability.
Before
Our product team is choosing an AI app builder for its next prototype. I want a simple page we can open during a planning meeting to compare the main tools. It should be quick to keep up to date and something we can actually trust.After
# Tool Scout: brief
## Starting brief
Our product team is choosing an AI app builder for its next prototype. I want a simple page we can open during a planning meeting to compare the main tools. It should be quick to keep up to date and something we can actually trust.
## Confirmed facts
Agreed on 2026-09-17.
### Scope of version one
- Compare five tools: Lovable, Bolt.new, v0, Replit, Figma Make. These form the initial shortlist for this exercise.
- Compare the five tools only. Do not recommend a winner yet. The team will decide after reviewing the evidence.
- No deadline. Keep version one small instead.
### The four comparison points (no more)
1. Cost for a small team. Monthly price of the cheapest plan a team of three could actually ship on.
2. Real app parts. Logins, database and payments, each labelled Built in / One-click link to outside service / Client wires it up.
3. Leaving. Can you export the code and run it somewhere else?
4. Security and data. Where the data lives and which security claims the tool publishes. Needs the most careful sourcing, so it's done last.
### Sourcing rules
- Use only the tool's own public pages: pricing page, docs, security or trust page. No third-party sources and no hands-on tests.
- Every claim carries the link and the date it was checked.
- If the tool's own pages don't say, the cell reads "Not stated". Never a guess.
### Trust rules
- Price only when confirmed. Otherwise the cell reads "Can't confirm: [requirement] not stated".
- "Not stated" is its own label, and looks different from "No".
- Security claims quote the exact wording, then add "Covers builder: stated / not stated".
## Assumptions
| Assumption | Source or open question |
|---|---|
| These five tools cover the team's needs | Open question: the shortlist has not been checked against team requirements (see Gaps). |
| These four points are enough to choose a prototype tool | Open question: not checked with the people who will build the prototype (see Gaps). |
| A security certification held by the company covers its AI builder | Open question: not verified. This is why claims show "Covers builder". |
| A monthly check by hand keeps the facts accurate enough to trust | Open question: not tested. |
## Gaps
- GAP: requirements interviews have not been run. The comparison points need confirmation from the team. Owner: the product lead.
- GAP: none of the shortlisted tools has been tested on the planned prototype. Owner: not assigned.
## Success criteria
- The team can open the page before a planning meeting.
- It covers all five tools on all four points.
- Every claim has a link and a check date, or reads "Not stated".
- No cell holds a guess.
- The product lead updates it by editing data.js only.This is where Core 2 picks up: keeping this file, and everything decided after it, from living only in a chat.
Give your team feedback they can act on
Use this free Claude skill to turn rough review notes into clear instructions: what needs to change, why, and how your team can check it's fixed.
Before
The page might end up saying a tool can't do something when that tool's site simply never mentions it. Feels risky for a planning meeting. Worth a look before launch.
After
| What the skill wrote | |
|---|---|
| Ask | Silence on a tool’s own pages must never be shown as “No”. |
| Why | A team that reads silence as “no payment support” may reject a suitable tool based on a claim the source never made. |
| Evidence | The agreed labels for points 2 and 3 are “Built in”, “One-click link”, “Client wires it up” and “No”. None of them is “Not stated”, although the sourcing rule in docs/brief.md requires it. |
| Change | Add “Not stated” as its own label for points 2, 3 and 4, styled differently from “No”. A “No” cell needs a link that actually says so. |
| Proof | Every “No” cell in data.js carries a link, and a second person spot-checks five of them against the live pages. |
