> ## Documentation Index
> Fetch the complete documentation index at: https://aidocs.ethanbragdon.icu/llms.txt
> Use this file to discover all available pages before exploring further.

# Write Better Build Requirements

> Define FORGE goals, constraints, acceptance criteria, validation requirements, and protected interfaces before a build starts.

# 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.

```text theme={null}
Add organization-level webhook management to the Developer Portal.
```

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.

```text theme={null}
- An organization admin can create and disable webhook endpoints.
- Secret values are not redisplayed after creation.
- Failed deliveries are visible in history.
- Existing API key management continues to work.
```

### 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.

<Tip>
  A build request should read more like a strong engineering ticket than a giant stream-of-consciousness prompt.
</Tip>