Between your prompt and the build sits a plan, and it's worth thirty seconds of actual reading, because it's the cheapest moment in the whole pipeline to change your mind. Edits to a plan cost a sentence; edits to a build cost a version.
What the plan card tells you
- The pages or screens it intends to build — the product's skeleton.
- The features it inferred from your prompt, including the ones you didn't say but it considered implied.
- The product type it chose — plain site, installable app, framework build, server-backed app. This decides what the build can do later (accounts and databases need the server-backed kind).
- Questions, occasionally — only when something genuinely forks the build.
Pushing back is plain language
Reply in the chat like you'd reply to a person: "drop the blog, add a pricing page", "make it two-player instead", "this needs user accounts". The plan revises and re-presents. There's no plan-editing syntax to learn — the same conversational register you'll use later for iterating on versions works here.
When to just approve
Most of the time. If the skeleton is right and the must-haves are present, approve — the details you're tempted to specify now are easier to judge on a working build in a few minutes. The two things worth catching at plan time, because they're structural: the product type (a static site can't grow accounts without a rebuild) and anything you know you'd reject on sight.