Turn a request into a project brief

---
name: "aboutcodex-project-brief"
description: "Turn an underspecified software or website request into an actionable project brief with observable acceptance criteria. Use when the user asks to scope or clarify a change before implementation."
---

# Project brief

Turn the user's requested change into a brief that someone can implement and review.

Read the supplied request and available project instructions. Separate facts already established from assumptions. Use repository evidence when it is available; do not invent framework choices, commands, deadlines, or customer requirements.

Describe the visible behavior that should change, the relevant surfaces, and the boundaries of the work. For each acceptance criterion, name an observable result and the evidence that would demonstrate it. Prefer concrete examples to broad terms such as "modern" or "optimized."

Ask about a missing detail only when different answers would materially change the work. Continue drafting the independent parts of the brief while awaiting that answer. Treat optional preferences as stated assumptions, not blockers.

Use references/NOTES.md for a compact acceptance-criteria worksheet. Adapt its fields to the task; omit irrelevant fields. If the user also asked for implementation, use the brief to continue that authorized work rather than stopping after planning.

Deliver a concise brief that distinguishes intended results, known constraints, validation evidence, and unresolved decisions. Do not expand the requested scope into unrelated features.