Content
68%Weight 40%Scale 1-5Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
The body is an exemplary lean rules document: dense, domain-specific, and free of filler, with clean two-section organization. Its weaknesses are the mirror of its strengths — no illustrative protobuf examples to make the rules executable, and no application sequence or conformance checklist to turn the rule list into a workflow. Anti-drift check: conciseness holds at 5, actionability and workflow clarity at 3, progressive disclosure at 4.
Suggestions
Add one short conforming protobuf snippet per section (e.g. an Update RPC with `google.protobuf.FieldMask update_mask`, and a public `RealtimeEvent` union member) so the rules are checkable against a concrete shape.
Turn the "when an Event or PubSubEvent variant must reach clients" bullet into an ordered same-change checklist with a final verification step (generated clients compile, compatibility notes updated).
Subdivide the two long bullet walls with sub-headers or move the event-mapping rules to a reference file to aid navigation.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is 60 lines of dense imperative rules with zero filler — "Resource `Update*` RPCs must use `google.protobuf.FieldMask update_mask`" — and no explanation of concepts Claude already knows. Every bullet encodes product-specific policy Claude could not infer, matching anchor 5 (lean and efficient; every token earns its place); the one long same-change bullet is packed with substance, not padding, so it does not drop to 4. | 5 / 5 |
Actionability | Concrete named types and constraints appear throughout ("`chatto.core.evt.v1.Event` for durable EVT facts", "Commands use specific verbs such as `Set`, `Change`, or `Refresh"), but there are no illustrative protobuf snippets or API skeletons showing what conforming output looks like, and several rules are abstract ("Cover the complete useful product event surface"). Anchor 3 (some concrete guidance but incomplete); not 4 because a designer could not fully execute these rules without worked examples. | 3 / 5 |
Workflow Clarity | The body is a flat rule list under two headers with no sequencing of when or in what order to apply them. The one quasi-workflow bullet ("update the dedicated payload, public union member, authorization and mapper coverage, … in the same change") enumerates artifacts but gives no order and no verification step. Anchor 3 (sequence/checkpoints implicit or missing); not 2 because the rules are individually unambiguous and well-grouped. | 3 / 5 |
Progressive Disclosure | Two clearly labeled sections ("### ConnectRPC Resource API", "### Realtime API") with no bundle files to reference, so single-file organization is appropriate. At ~60 lines of dense, unbroken bullet walls it slightly exceeds the under-50-lines single-file heuristic and could use sub-organization or a split reference for the event-mapping checklist — anchor 4 (good structure; minor organization gaps); not 5 because navigation within each section is weak. | 4 / 5 |
Total | 15 / 20 Passed |