task-creation
A work item has one reader, and the two possible readers pay opposite costs. A human implementer picks the item up later and pays for volume: unstructured and over-long prose is what developers name among the problems that most delay a fix. An autonomous agent is handed the item directly and pays for absence: a large share of real issues are underspecified for one, and naming the files a change touches is the single largest measured lift in its success rate. The opposite costs — over-specification to an agent, under-specification to a human — are not established, so no rule here trades on them. Establish which reader the item is for, and let that decide what goes in.
Write only what was run or read. Completing a missing section trades absence for error: the item stops failing for what it omits and starts failing for what it asserts, and a machine writer buys structural completeness while reproducibility barely moves. Completeness is not accuracy. Plausibility survives a style checklist, so the check is verification against the system — run the path, read the code, capture the output — and whatever could not be verified is marked as such inside the item.
A filed item cannot answer a question. Interrogating a human recovers most of what underspecification costs, and a model cannot reliably tell an underspecified task from a complete one. Two consequences hold together: everything the implementer needs is front-loaded, because the queue has nobody to ask, and the writer cannot trust its own judgement that the item is complete, which is what the approval gate is for.