Conciseness

The body is dense with non-obvious specifics ("fire-and-forget, so the originating call returns before handlers finish", "empty-as-wildcard, exact-match-otherwise semantics") and explains nothing Claude already knows. It misses anchor 5 because the "Reach for them when" bullets largely restate the earlier "When to Use" bullets ("derived projections, audit logs, notifications" vs "a projection, audit log, or downstream notification"), and the deprecation notice repeats the frontmatter verbatim.

Actionability

The "How to bind" section gives a complete, executable `iii.registerTrigger({...})` TypeScript example with annotated config fields, the functions section enumerates concrete operations, and "call `iii get function info` on the trigger type or handler function id" is a specific command. Below anchor 5 because no handler implementation is shown — the `{ unauthorized: true }` return and `stream::update` op application are described but not demonstrated.

Workflow Clarity

The bind workflow is a clear numbered sequence ("1. Register a handler... 2. Register the trigger") followed by the matching semantics, and no destructive or batch operation triggers the anchor-3 cap. It stops short of anchor 5 because there is no verification step (e.g., confirming the trigger fires or the subscription was accepted) after binding.

Progressive Disclosure

The body (~70 lines) is cleanly sectioned (When to Use, Boundaries, Functions, Reactive triggers) and appropriately defers event-payload detail to the `iii get function info` command rather than inlining it; no bundle files exist to nest or bury. It is held below anchor 5 because at this length and API breadth a separate reference for event shapes or handler patterns would lighten the main file, and the guideline's under-50-line exception for a flat single file does not strictly apply.

Specificity

Lists several concrete capabilities — "a CRUD function surface", "reactive triggers that fire on item changes", "WebSocket subscriber lifecycle", "build live backends without polling" — with only minor gaps (no individual operations like set/update/delete are named). It is above anchor 3 (domain plus only 1-2 actions) but below anchor 5, which expects comprehensive coverage of specific actions.

Completeness

Both questions are answered: the "what" is the durable stream CRUD-plus-triggers surface, and "reach for it to build live backends without polling" is an explicit 'Use when'-equivalent clause, so the anchor-3 cap for missing trigger guidance does not apply. It is below anchor 5 because the 'when' is a single general scenario rather than a set of concrete trigger phrases.

Trigger Term Quality

Good natural-keyword coverage: "real-time streams", "live backends", "without polling", "WebSocket", "CRUD", "reactive triggers", "subscriber" are phrases a user building this kind of backend would plausibly say. It falls short of anchor 5 because common synonyms like "pub/sub", "broadcast", "presence", or "push updates" are absent.

Distinctiveness Conflict Risk

The specific combination of "CRUD function surface", "reactive triggers", and "WebSocket subscriber lifecycle" carves a clear niche distinct from generic state/KV or WebSocket skills. Minor overlap risk remains with sibling real-time or state-store skills, matching anchor 4 rather than the minimal-conflict anchor 5.