Conciseness

The body is a lean router with no padding and no explanation of concepts Claude already knows ("This guide never restates argument shapes — the live tool schema in your session is the authoritative source"). Minor trimmable redundancy keeps it below the top anchor: the declined-approval rule is stated twice nearly verbatim ("if approval is declined, stop and report — do not retry the same effect through another route" vs "On declined approval, stop and report — never re-attempt the mutation through a different route"), and the mutation-boundary rule appears in both the intro and Global rules.

Actionability

Fully concrete guidance: exact fully-qualified tool names, per-intent sequences in the routing table (e.g. "kb_list → kb_search → kb_read", "command -v check → cli_list → cli_search → cli_install (approval)"), explicit approval gating per tool, and a linked reference file for every row. For an instruction/routing skill this is copy-paste-ready equivalent — the common cases are all covered.

Workflow Clarity

Clear routing-level sequence with real checkpoints ("Check availability first", "resolve IDs first; needs approval") and explicit error-recovery feedback loops ("read the message and correct the call; don't silently retry the same arguments"). Falls just short of the top anchor because per-operation output validation and deep per-domain sequencing are deferred to the references rather than present in the body.

Progressive Disclosure

A true overview router: it carries only global rules and the intent → tool → reference table, and every one of the 11 referenced files (web.md, automation.md, knowledge.md, documents.md, memory.md, autonomy.md, sessions.md, outputs.md, cli.md, skills.md, mcp.md) exists and is clearly signaled per intent row. References cross-link only to siblings (e.g. web.md → automation.md), staying one level deep with no nesting.

Specificity

It names the domain ("Cherry tool routing") and enumerates concrete capabilities ("bun, uv, rg, knowledge, memory, schedules, skills, MCP, web"), which is more concrete than the anchor-2 example "Processes PDF files", but the only actions stated are the generic "routing" and "Read" — no concrete action verbs describing what it does with those domains. Sits between anchor 2 (minimal/generic actions) and anchor 4 (several specific actions), so 3 is the best fit.

Completeness

Both parts are present: the what ("Cherry tool routing: bun, uv, rg, knowledge, memory, schedules, skills, MCP, web") and an explicit when-equivalent ("Read before shell workarounds"), so the missing-trigger cap of 3 does not apply. The when is narrow — it covers only the anti-pattern trigger, not affirmative cases — fitting anchor 4 ("'when' could be more explicit or specific") rather than anchor 5.

Trigger Term Quality

Keywords like "bun, uv, rg, MCP, web, memory, schedules" are terms a user would plausibly say, but coverage is domain-label level and misses common natural phrasings and synonyms ("search the web", "schedule a task / remind me", "install a package or CLI", "generate an image", "knowledge base"). Matches anchor 3 ("Some relevant keywords but missing common variations or synonyms") more than anchor 4's fuller natural-term coverage.

Distinctiveness Conflict Risk

"Cherry tool routing" plus distinctive terms (bun, uv, rg) carves a clear niche scoped to Cherry Studio's tool surface with minimal conflict risk. Minor overlap remains because bare words like "memory", "web", "schedules", "skills" are generic enough for other skills to claim, matching anchor 4 ("Mostly distinct; minor overlap risk") rather than anchor 5's fully distinct triggers.