Content
63%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 well-conceived router whose body is efficient and clearly sequenced, with good error-recovery guidance. Its execution is undermined by the bundle itself: the manifest and core files that steps 1–4 depend on are missing, forcing every routing instruction through broken references, and the fragment-to-shared-module chain adds a second level of indirection.
Suggestions
Ship the missing navigation layer — add manifest.yaml and static/core/tools.md and routing-and-ops.md to the bundle, or rewrite steps 1–4 to route directly through the files that do exist (references/workflows/wf1–wf6.md plus the shared modules).
Inline a compact fallback mapping of each workflow value to its actual file path (e.g., multi-source-search → references/workflows/wf1-multi-source-search.md) so routing works even without the manifest.
Reduce the two-hop indirection by declaring the shared modules each workflow needs at the router level (or in the manifest), so the reader knows the full load set before opening a fragment.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The router body is lean and assumes competence — no concept explanations, just loading and routing directives like "For a new task, load the core and matching resources below. Reuse already loaded guidance on follow-ups". Minor trimmable redundancy keeps it below anchor 5: the core files ("core/tools.md", "core/routing-and-ops.md") are re-listed in step 4 after already being enumerated in step 1, and step 5 re-enumerates on-demand file paths that the manifest's "references.on_demand" table already declares. | 4 / 5 |
Actionability | The routing protocol gives concrete, sequenced directives with specific error handling ("Report specific tool failures and continue with remaining tools; broaden terms when there are no results; fall back to manual generation from MCP-fetched metadata if a script fails twice"), but the central instruction "Read [manifest.yaml](manifest.yaml)... Also read every file listed under always_load: static/core/tools.md, static/core/routing-and-ops.md" points to files that do not exist in the bundle, so key executable details are unavailable. It is above anchor 2 because the workflow detection and fragment-loading steps reference real files with specific directives, but below anchor 4 because the foundational loading step cannot actually be executed. | 3 / 5 |
Workflow Clarity | A clear 5-step sequence (load manifest/core → detect workflow → load matching fragments → run in order → on-demand references) with an explicit checkpoint ("State the detected workflow(s) in one short line before proceeding") and feedback loops for error recovery (report-and-continue, broaden terms, fallback after two script failures). Below anchor 5 because the body contains no output-validation steps of its own — verification details live only in the workflow fragments — and the sequence's first step depends on the missing manifest and core files. | 4 / 5 |
Progressive Disclosure | Scored against the actual bundle: the router concept is well designed with clearly signaled references, and the workflow fragments (references/workflows/wf1–wf6), shared modules (dedup-engine.md, citation-parser.md, search-strategy.md, ris-bibtex-format.md, source-tiers.md) and scripts all exist. However, the primary navigation layer — manifest.yaml, static/core/tools.md, and static/core/routing-and-ops.md, which the body designates as always-load — is absent from the bundle, and the workflow fragments add a second indirection hop to shared modules (e.g., wf1 links to ../dedup-engine.md and ../source-tiers.md). This lands at anchor 3: real structure with genuine organization problems, rather than anchor 4's "most content appropriately placed". | 3 / 5 |
Total | 14 / 20 Passed |