The first build is rarely the one you ship. ContentForger is built for the second, third and fourth: once a build has finished, the Generate page treats it as a project, and every change request builds on the files you already have. This tutorial explains how that works and gives a rhythm that gets from first prompt to a passing build in a handful of steps.
How change requests work
When a build finishes, the form changes. The template and style selectors disappear, the prompt box is relabelled Change request, and up to three suggested next changes appear as buttons under the file list. Clicking a suggestion fills the box; Apply change starts the build.
A change request is a new build linked to your project. The planner reads the project's current files and your request, then lists only the files that need to be added or changed, and any that should be deleted. Those files are written and saved one by one, exactly like a first build; every other file is carried over untouched. The ZIP always contains the whole project, not just the changed files.
Four consequences follow from that design.
Each change request counts against your daily change allowance, which is separate from new apps: 10 a day on Free, 300 on Pro and 3,000 on Agency, reset at 00:00 UTC.
The project keeps its model. A change request runs on the model that built the project, so a Free project started on Claude Sonnet 5.5 is changed on Sonnet 5.5.
The template and style apply only to the first build. A change request does not re-apply them; if you want a different style, say so in the request ("restyle the hero in the playful style") or start a new project.
One build at a time. A change request can only start once the current build has finished. If a build was paused or the connection dropped, reopen its link and let it complete first.
New project, the link above the file list, clears the project and brings the template and style selectors back.
The most important habit: one change per request
Because the planner decides which files to touch, a request that bundles five features produces a large plan that is harder to review. One concrete change per request keeps the plan short, keeps the diff small, and makes it obvious what to check afterwards. "Add a settings page where users change their display name" is a good request; "add settings, billing, an admin view and dark mode" is four.
Name the files when you know them. "Fix the date format in components/OrderList.tsx" gives the planner a precise target and usually results in a one-file plan.
A five-step rhythm
Here is a sequence that works for most small apps. On Free it fits comfortably in one day: one new app and four change requests.
Step one: the first prompt
Name the user, the core loop, the pages, the data and the stack, and state the business rules in a line each. Pick a template if one is close; its prompt is prepended to yours. If you used the brief tool first, start from its suggested prompt and add the business rules; Tutorial: Plan an App With the AI Project Brief covers that. Ask for the core loop first, not every feature.
Step two: read the plan and the file list
Before changing anything, read what was built. The file list shows every planned file with its purpose, and the viewer shows each file in full. If something you asked for is missing, that is your first change request: "Add the favourites page described in the first prompt."
Step three: the data layer and schema
If the app stores data, ask for the schema and the data-access code to agree: "Make supabase/schema.sql match every column the code uses, with RLS policies on user-owned tables." This is the request that saves you an hour at deploy time.
Step four: the first real feature beyond the loop
Now the payment tier, the settings page or the admin view, whichever single feature matters most. One feature per request.
Step five: the build errors
Download the ZIP, install, run the production build on your machine, and paste the first error into the change request box with "Fix this error." One error per request is slower per step and faster overall, because fixing the first error often resolves the rest.
When to start a new project
Start fresh when the direction changes, when you want a different template or style throughout, or when the project is near your plan's file limit (24 files on Free, 40 on Pro, 60 on Agency). Carry the essentials forward in the new first prompt: say what exists, paste the schema if there is one, and say what you want next.
On very large projects the planner may not see every file in full, so precise requests that name the files to change matter more as a project grows.
Keeping your local project and ContentForger in step
The planner works from the files saved in ContentForger, not from your machine. Edits you make locally, and quick edits in the viewer's edit mode, are not part of the project it sees. Two practices make this safe.
- Commit before you copy a change request's files into your local project, then review the diff before committing again.
- When a hand-edited file needs a generated change, paste your current version into the change request and ask for the change against that version.
The viewer's edit mode is useful for a one-line fix before download, but Copy all includes those edits and the ZIP does not; for anything beyond a line, edit locally under version control.
What a change request cannot do
It cannot run your code; there is no execution inside ContentForger, so build errors are found on your machine. It cannot see edits you made outside ContentForger unless you paste them. And it does not raise your daily allowance: on Free, ten change requests a day is the ceiling however they are phrased.
For the mechanics behind all of this, from the plan to the file tree, read How ContentForger Turns a Plain-English Brief Into a Deployable App, especially its chapter on change requests. For the fuller craft of the first prompt, What Makes a Good Prompt for a Code Generator remains the reference.
