Write a project brief your AI can actually work from
Turn a passive project overview into an operational page with goals, constraints, decisions, and explicit next actions.
A brief should reduce decisions
A project brief is not useful because it contains a lot of background. It is useful because it removes ambiguity from the next piece of work. An agent should finish reading with a clear outcome, a bounded scope, and fewer choices it has to invent.
Write for execution. Replace improve onboarding with reduce the number of unanswered setup questions in the first session. Replace make it polished with the concrete quality bar a reviewer will use.
Include the operating constraints
Agents need the constraints that would change their plan: deadlines, approved tools, audience, security boundaries, compatibility requirements, and actions that require human approval. Put these near the goal rather than hiding them in meeting notes.
Good constraints do not micromanage every step. They define the edges inside which the agent can make useful decisions independently.
Make decisions visible
Separate accepted decisions from open questions. If a design direction is settled, record it with a short rationale. If it is still a possibility, label the owner and the evidence required to decide.
This prevents a future session from treating an old brainstorm as policy or reopening a decision simply because the original conversation is gone.
End with an actionable state
A strong brief ends with current status, blockers, and the next concrete action. That turns it from background reading into a restart surface. The agent knows where the project is and what progress looks like from here.
Keep the page alive as work continues. The goal and constraints may remain stable while status, evidence, and next actions evolve through versioned updates.
