hirdlisted

# Work through hird Use the connected hird MCP tools. Treat the queue as shared live state: other agents and a human may be using it at the same time. ## Get work - If the user names a task number, call `task_claim` for that `seq`. - If the user says to work the queue without naming a task, call `task_next`. Call it again after finishing each task until it reports that nothing is workable. - Claim before changing files. If another agent holds the task, tell the user who holds it instead of doing the same work independently. - Read the claimed task, its `recalled` facts, and its `built_on` entries before starting. `built_on` is what the tasks this one depends on said when they finished — the context the dependency order exists to hand you. An entry marked `provisional` is done but still under review; its work could be sent back and reopened while you build on it. - If the claim carries `previously`, the task has been held before, and whatever that holder left uncommitted is in your working tree looking like code that was always there. Re-read the files it names before building on or over them; `hird diff <seq> --tenure <n>` (named in the sentence) shows exactly what that round changed. - If the claim carries `questions`, read every answer before continuing. An earlier holder stopped specifically because guessing would have been wrong; the recorded answer is part of the task brief. ## Work safely 1. Call `task_scope` as soon as you know which file