Content
81%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.
A strong router body: deterministic, precedence-ordered routing with executable commands, explicit disambiguation, and verbatim user-facing output. Its main weakness is redundancy — the 'By task' section and the 'Pick a track' table restate the same routes and caveats — plus referenced files that cannot be verified against the bundle.
Suggestions
Collapse the duplication between the 'By task' section and the 'Pick a track' table into a single routing surface (keep the table, replace the prose section with the few rules it uniquely contributes, such as the SDK-vs-build-target precedence), cutting roughly a third of the body.
Move the long per-row caveats (onboarding carve-outs, React framework scope, docs-vs-platform distinctions) out of the table cells into RULES.md or peers.yaml so the table stays scannable and each rule is stated once.
Verify the referenced files (RULES.md, peers.yaml, peers.schema.json, sendbird-data-migration.md) ship with the skill bundle — none are present here — and consider placing them under references/ with paths confirmed, so the one-level-deep links resolve.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | There is no concept padding — the body never explains what Stream or a router is — but the routing rules are stated multiple times: the 'By task' section and the 'Pick a track' table repeat the same audit, migration, and peer-signal routes, and caveats like 'install on demand' and 'no peer signal present' appear in several forms. This matches the score-3 anchor ('mostly efficient but includes some unnecessary explanation or could be tightened') better than score 4, where only minor instances would be trimmable — here whole rows duplicate earlier bullets. | 3 / 5 |
Actionability | Guidance is fully executable: exact CLI commands with when-to-use ('getstream init', 'getstream api <Endpoint>', 'getstream skills stream-swift'), the exact disambiguator question to ask ('Want me to look up the SDK method (docs) or run it now via CLI?'), the verbatim menu to render, and a concrete recovery step for the known 'Unknown skill' failure (Glob the peer path, run its install command, before calling Skill). This is copy-paste-ready routing behavior, matching the score-5 anchor. | 5 / 5 |
Workflow Clarity | The multi-step routing process is explicitly sequenced with precedence ('matched before the docs rows', 'takes precedence over the web stream-react rows'), a deterministic no-probe classification stage, error-recovery checkpoints (ask one disambiguator and wait; never call Skill before the Glob to avoid the 'Unknown skill' error; ask 'Unity or Unreal?' rather than guessing), and clear handling of edge states (bare /stream, missing CLI, uninstalled peers). The feedback-loop analogs a router needs are all present, matching the score-5 anchor. | 5 / 5 |
Progressive Disclosure | Structure is good: routing logic and the CLI surface live in SKILL.md while cross-cutting rules, peer routing data, and the Sendbird data-migration procedure are each split into a separate file with clearly signaled links ([RULES.md], [peers.yaml], [peers.schema.json], [sendbird-data-migration.md]). It falls short of score 5 because the referenced files (RULES.md, peers.yaml, peers.schema.json, sendbird-data-migration.md) do not exist in this bundle — there is no references/ or scripts/ directory to verify them against — and the routing table itself carries a lot of detail (long multi-clause cells) that could live in the referenced peer/routing files. | 4 / 5 |
Total | 17 / 20 Passed |