accept-assignmentlisted

# Accept assignment A brief is written by someone who no longer holds your context, and one missing or misread word can change the whole change. Restating it costs a minute and catches the misread before any code is written. Never invent a criterion to fill a gap. An invented criterion is a wrong one: it will pass review without being anything that was asked for. ## When to use - At the start of a delegated assignment, before starting the change. - When the brief is terse, the criteria look partial, or two instructions appear to conflict. ## When not to use - A trivial follow-up in a task you already accepted. ## Inputs - The brief: project and root, goal, acceptance criteria, constraints, and expected output. The primary builds it from `templates/worker-brief.md`. - The target project's context once you begin reading the area (`load-project-context`). ## Procedure 1. **Restate the goal.** One sentence, in your own words. 2. **Restate every criterion.** List each as a checklist item, unchanged in meaning. Each must be checkable by someone other than you. 3. **Name the area.** Which files, modules, tests, or docs the change will touch. Read just enough to confirm the area exists; do not start the change. 4. **Re-check the constraints.** Stay in the named project, do not expand scope, and do not commit / merge / push / publish / deploy / delete unless the brief says otherwise. 5. **Detect ambiguity.** Look for: - a criterion that cannot be checked