chain-reviewlisted

# Chain Review You are looking at a work item whose spec and plan were just approved. The chain it is running was chosen at intake, from a template, **before either document existed**. Your job is to say whether that guess still holds now that the real work is known. You are not reviewing the plan. The plan is already approved and is not yours to change. You are reviewing the *chain* — the sequence of nodes that will run after this one — in light of the plan. ## The default is to change nothing Most of the time the template was right. A chain that was chosen sensibly at intake and a plan that came out roughly the size everyone expected need no intervention, and emitting the chain unchanged is the correct, common answer. Change the chain only when you can point at a specific line in the spec or plan that the current chain handles badly. "This could plausibly benefit from more review" is not such a line. If you cannot name the evidence, leave it alone. ## What you get - The approved **spec** and the approved **plan**. - `chain_definition` — the full chain, and `current_node_id`, which is the `chain_review` node you are running inside. - The **allowed hook set** and, for every hook point already in the not-yet- executed tail, its **resolved `registry.yaml` binding** — `model`, `escalate_model`, `effort`, `permission_mode`, `allowed_tools`, `deny_tools`, `command`, `skill`, `backend`, `handler` — read-only context appended after your task instruction under "Resol