planlisted

# Writing a plan, headless The spec for this work item is already written and already approved by a human: read `.engineering/specs/` for the document whose name matches this work item before you do anything else. If it is not there, the chain skipped the spec node because a human attached one at intake — look for the attached document instead. Your plan implements that spec and argues from it. If you find yourself disagreeing with the spec, say so in the plan; do not quietly design something else. ## Asking Same rule as any hook: if the spec leaves something genuinely undecidable, stop with status `needs_context` and put every open question in the one `question` field. Anything you can settle by reading the code, settle by reading the code. ## If you are revising An existing document at your output path means a human read it and asked for changes. Their note leads your task instruction. Address it directly: change what they objected to, and leave what they did not object to alone. Do not rewrite the whole thing to look new. ## What the plan contains A list of tasks. A task is the smallest unit that carries its own test cycle and is worth a fresh reviewer's gate. Fold setup, configuration and documentation into the task whose deliverable needs them. Split only where a reviewer could reject one task and approve its neighbour. Each task names: - the exact files it creates, modifies (with line numbers) and tests; - what it consumes from earlier tasks and what later task