Modify existing projects
FORGE can be more valuable on an existing product than on a greenfield project—but only when it understands what must be preserved.
Prepare the codebase
Before starting the build:
- connect or provide the correct repository/project snapshot
- identify the branch or revision
- include architecture or contribution docs when relevant
- identify protected public interfaces
- identify the normal build/test commands
- describe any migration constraints
Ask FORGE to inspect before changing
For cross-file work, repository intelligence should locate the existing pattern and likely change surface before generation begins.
A strong request sounds like:
Preserve conventions
Existing projects often contain conventions that matter more than a generic best practice:
- API wrappers
- error handling
- component architecture
- naming
- environment/config loading
- database access patterns
- test helpers
Prefer consistency unless the task explicitly authorizes a refactor.
Minimize change surface
A focused feature should not cause unrelated rewrites. The build plan should identify which files are expected to change and explain why when the change expands beyond that surface.
Validate against the repository
Use the project’s real supported validators where possible. A generic syntax check is not a substitute for the repository’s own strict build or test suite.
Source drift
If the repository changes materially after the build starts, refresh context and create a new build against the updated revision rather than assuming the existing artifact contains those changes.
Review generated migrations, authentication changes, billing changes, infrastructure changes, and destructive data operations especially carefully before deployment.
