goal-setter

# Goal Setter Turn a rough request into a compact `/goal`: the result to achieve, the evidence that proves it, the boundaries that matter, and when Codex should finish or stop. A Goal is a completion contract, not an implementation plan or a second task system. Prefer the shortest Goal that preserves the user's real outcome. State each rule once. Leave file discovery, implementation order, agent count, models, and tool details to the running Codex task unless the user fixed them. ## Decide whether a Goal fits Use a Goal when one objective may take many checks or turns and completion can be judged from tests, artifacts, runtime state, screenshots, measurements, sources, or a clear rubric. Use a normal prompt for a small edit, explanation, or review. If the request is subjective and has no usable completion test, help define the test first instead of pretending the Goal is verifiable. ## Understand before drafting If tools are needed, first tell the user in one or two sentences what evidence you will inspect. Read the smallest useful set of code, docs, sources, or existing artifacts. Do not begin implementation during Goal intake. Answer three questions: 1. What result does the user actually need? 2. What observable evidence would prove it? 3. What must be learned before those answers are safe? For a working system or user-facing artifact, trace the real path from user input to the expected output or state. A mock, screenshot, scaffold, fake service, or isolated compo...