Gate 01 · Project Brief

The brief is the north star. It says what you’re building, who it’s for, and why it matters, and every gate after it reads from here. Time spent getting this right pays off nine times over.

You don’t need much to start. A description of the product, the problem it solves, and who has that problem is enough for the Architect to draft a first version. Better still, hand it what you already have: a one-pager, some notes, a pitch deck, a few competitor links. It reads all of it and pulls out far more than you’d type.

A good brief is one a stranger could read and understand what you’re making and why. If the target user or the core problem is fuzzy here, features will be fuzzy too, and so will everything downstream.

Refine the draft in the chat, then commit it. Committing unlocks the next gate. You can always come back and edit, but remember that changing the brief flags every downstream gate that depended on it.

Rewriting later

Reworking the brief after you’ve built downstream gates is fine, but expect a wave of stale flags and a Downstream Review to reconcile them. Cheaper to get close now.

Output: project-brief.md.