How to structure a Master Build Prompt for a coding agent

State a verifiable task

Say what should change, for whom, and which current requirement it serves. Instead of “build the whole platform,” specify “let an authorized user create a booking, reject slot conflicts, and test both outcomes.” Supply the relevant architecture and files rather than secrets or a needless full repository dump.

Separate confirmed facts from assumptions and decisions the agent may not make alone. If acceptance is ambiguous, seek clarification before a consequential change.

• Goal, scope and affected user.
• Architectural context and source of truth.
• Protected resources and out-of-scope work.

Make permissions and verification explicit

Name the checks: unit and integration tests, negative authorization cases, lint and production build where relevant. Reading files is not permission to write; approving a plan is not permission to deploy or migrate data. Require a final report of changed files, validation and remaining uncertainty.

A concise example: “Use existing contracts; do not change production D1 or secrets; add a cross-owner denial test; stop before deployment.” This is more actionable than a stack list without reasons.

• Separate Git, deployment and migration permissions.
• Test failure paths as well as the happy path.
• Ask for reproducible evidence in the handoff.

Treat the brief as an input, not authority

A prompt does not guarantee correct code or replace expert review and owner approval. A new security boundary or unresolved product decision may require a new question. ArchQore compiles a brief from an approved foundation; separate readiness and authorization gates keep that brief from silently becoming an execution grant.

• Never paste passwords or tokens into the brief.
• Do not waive checks merely to finish quickly.
• Review the final diff before merge and deployment.