Write an AI Task Brief with Clear Acceptance Criteria

A useful brief names an observable outcome, enough context to locate the work, and evidence that would establish completion. OpenAI’s prompting guidance emphasizes concrete context and verification; the acceptance matrix below is our editorial exercise.

Know which copy of the project you are discussing. Read its setup instructions before naming commands. If the test command is unknown, write “identify the documented test command” rather than filling in a plausible one. Use the local AI Task Brief Builder if you want a Markdown draft.

Goal: a visitor can still identify the email field after entering text. Context: contact.html contains an email input with a placeholder but no visible label. Scope: markup and its existing form stylesheet; no dependencies, endpoint changes, or deployment.

• Deliverable: a small diff and a short before/after explanation.
• Acceptance: a visible label is associated with the email input; keyboard order remains name → email → message → submit; the page has no horizontal scroll at 390px.
• Stop: if the input is generated elsewhere, identify that source and ask before expanding the file boundary.

1. Separate requirements from suggestions. “Keep a visible label” is a requirement; “put it above the box” may be a suggestion unless layout is fixed.
2. List what may change and what must remain unchanged. Include existing uncommitted work in the protected set.
3. Pair each acceptance criterion with an observation: inspect the label association, tab through the controls, resize the viewport.
4. Ask the agent to return a plan before modification if it cannot identify the source file or verification path.

The resulting brief should let another person reject an incomplete patch without interpreting your mood. It should not require a whole-site redesign to satisfy one field-label problem. Blank optional facts stay blank until someone checks them.

Pause when two requirements conflict, such as “never change layout” and “add three always-visible paragraphs.” Decide which requirement takes priority. Do not let the agent quietly choose a new scope just to finish.

• Does every requirement have a pass/fail observation?
• Are commands sourced from this project rather than invented?
• Would the brief still make sense in a new conversation without the earlier chat?