task-authoringlisted

# Task authoring The executor is an agent with none of your context. Everything you leave implicit becomes a coin flip you delegated. ## Titles: for scanning, not describing - **The title is the outcome in one clause, <=70 chars, with no `word: ` prefix of any kind** — not `feat:`/`fix:`/`chore:`, and not an area prefix like `api:`/`docs:`/`ci:` either. The prefix burns the highest-value characters in the title and puts the grouping somewhere no filter can reach. - **Area and type live in labels**: `area:<x>` (exactly one, project-defined) and `type:feat`/`type:fix`/`type:chore` (exactly one). - **Containers are labelled `epic`**, not prefixed. - Vocabulary comes from the project's declared label set. - **Outcome, not symptom or activity** — "runs fail loudly on infra errors", not "investigate why errors surface as normal replies". A finding-shaped title goes stale the moment work starts; an outcome-shaped one *is* the acceptance criterion. - Evidence, issue/PR numbers, and "follow-up to X" belong in the body; past the 70-char limit most tracker UIs truncate anyway. - **Mark non-work items by label** (decision, handoff, meta) so they never masquerade as buildable work. - Before renaming anything, grep for what points at the old title by exact string (hooks, docs, automation) and exempt those. ## Acceptance criteria must be able to fail - **Run every criterion against today's baseline before writing it.** A criterion that already passes detects nothing