Write better build requirements
FORGE can plan more reliably when it knows what must be achieved and what must remain unchanged.
Describe the outcome
Start with the result you need.
Then add the constraints that define success.
Include these five sections
Objective
What should exist when the build is complete?
Existing context
Is FORGE creating a new project or modifying an existing repository? Which project, branch, framework, or architecture matters?
Protected interfaces
List public APIs, database fields, routes, component props, or deployment behavior that must not change.
Acceptance criteria
State observable success conditions.
Validation
Say which validation matters: strict TypeScript, unit tests, build command, lint, schema validation, packaging, or another supported check.
Avoid contradictory requirements
If a request says “do not change the API” and also requires a feature that needs a new API route, FORGE needs the conflict resolved. Make clear whether adding an endpoint is allowed while preserving existing ones.
Do not over-specify implementation unnecessarily
If the architecture already contains a pattern, ask FORGE to preserve that pattern rather than dictating every file path from memory.
Separate facts from preferences
Mark mandatory constraints separately from preferences. This gives the planner room to make a sound implementation choice without violating product requirements.
A build request should read more like a strong engineering ticket than a giant stream-of-consciousness prompt.
