A hook fires when the agent tries to act, and it evaluates a predicate over the call. "Never edit the generated-code directory" needs one input: the path [11]. The predicate is total, it is fast, and there is nothing to arbitrate. That is why the playbook's three examples work [11]. It is also why they are the easy cases. None of the three reads anything other than the path [12].
Now take the rule that domain code depends inward only, or the deprecation that covers checkout but not billing until next quarter [13]. The first needs the import graph after the change, not the filename. The second needs the decision, the scope it covers today, and what the diff proposes, all three at once [14]. A rule can be binding in one subsystem and irrelevant next door, and a newer decision can supersede an older one across part of the tree only [15]. As the dev.to write-up has it, that stops being instruction-following and becomes evaluation [14].
Ordering is where retrieval gives out. If two ADRs cover the same subsystem and one supersedes the other, the newer has to win on every call, not on the calls where its embedding ranks higher [16]. The write-up's prescription is to resolve applicability deterministically, with precedence, and let retrieval feed context into that resolution instead of casting the deciding vote [17]. That is the right shape in my context, with one condition attached: it only works if supersession is recorded somewhere a machine can read it. An ADR is documentation with a commit hash attached until something is actually built to evaluate it.
That gap is the adoption bill. Most teams already keep these decisions as ADRs, and the artifact chain gives them a natural home as committed files [18]. Compiling them is a different job. It transfers cleanly to a repo whose decisions are dated, scoped, and expressed as constraints over something machine-visible, such as paths, import graphs, dependency manifests, or migration targets. A decision recorded as a preference compiles into a check that passes everything, and someone has to maintain the supersession links by hand, which is the kind of upkeep that quietly stops happening once nobody's job depends on it.
The structural argument for doing it is the playbook's own. Because the check runs before the action rather than after, the verdict names the decision that was evaluated, what the change proposed, and why it was allowed or blocked [19]. That is an artifact, and every other stage in the chain already commits one [4]. The gate that decides is still the one stage in that chain that owes the system an artifact of its own.
Two sourcing notes. I have the playbook's sentences secondhand, through the dev.to piece, including the line that a policy which must always hold needs something deterministic behind the skill [9]. And the author of that piece endorses the model before arguing it is short a control surface [20], which is an argument with a product shape. The load is still carried by the vendor's own sentence about deterministic backstops [9], plus its admission that a skill is advisory [8], and by the write-up's reading that skills make violations rare while hooks make them close to impossible [21].
