Conciseness

The body is mostly tight domain-specific routing rules, but key rules are repeated many times: "Never 由本 skill 直接执行 ontology CLI" appears in the intro, the 分工 table, the 职能矩阵, and 注意事项 (4+ times), and 禁止交叉兜底 is stated both as 总入口原则 #6 and again verbatim in its own section. This is the 3 anchor (mostly efficient but could be tightened); not 4 because the repetition is substantial across a ~340-line body, not minor.

Actionability

Concrete, near copy-paste-ready guidance throughout: the full `ontology --user-id <accountId> metric <subcommand>` command block, JSON body examples for `bkn object-type query` including the real InvalidParameter error case, and field-level handoff contract tables with 缺失处理 for every parameter. It falls short of 5 due to broken double-backtick markdown in two spots (``bkn object-type list`), and KN-id placeholders (`<填入KN id>`) that require manual fill-in before the core flow runs.

Workflow Clarity

Sequencing is genuinely strong — the 5-step 编排总流程 plus per-branch checkbox lists (找表/指标管理/问数进度) with explicit stop conditions ("占位未填 → 告知用户并停止", "缺失则向用户索取，不得编造") and a dedicated failure-handling section. However the metric-management branch includes the destructive `ontology metric delete <kn-id> <metric-id> -y` with `-y` auto-confirm and no pre-deletion validation/verification step, which per the rubric's destructive-operation rule caps workflow_clarity at 3.

Progressive Disclosure

The document is well-sectioned with headers, but there are no bundle files at all (no references/, scripts/, or assets/ in this skill), and content that clearly belongs in a reference file is inlined: the ~20-line metric command reference duplicates what is already pointed to at ../ontology-core/references/metric.md, and detailed SQL/JSON examples sit inline in an already ~340-line file. This matches the 3 anchor (some structure, content that should be separate is inline); not 4 because the bulk command reference inlining is more than a minor organization gap.

Specificity

The description lists multiple concrete actions with comprehensive coverage: "负责 kn 分域、上下文注入（accountId / date）、多候选 KN 时的 LLM 决策、问数分支的 SQL 生成" plus routing metric CRUD/搜索/校验/查询数据/试运行 to the `metric` command group. It matches the 5 anchor (multiple specific concrete actions, comprehensive) and is not the 4 anchor since no meaningful capability of the orchestration role is left out.

Completeness

Both what and when are explicit: the what is the enumerated orchestration responsibilities, and the when is "当用户提出任何数据类自然语言任务、或需在多条业务 KN 间切换时使用" with concrete trigger scenarios. This mirrors the 5 anchor example's structure; it is not 4 because the when-clause is already explicit and scenario-based rather than needing more specificity.

Trigger Term Quality

Natural trigger terms are present ("数据资产、取数、指标、表/视图、治理职责…统计或分析", "当用户提出任何数据类自然语言任务…时使用"), but coverage leans on internal jargon (KN, ontology CLI, smart-search-tables / smart-ask-data) and misses common lay variations like 查数据/报表/看板. Good coverage with a few natural terms missing — the 4 anchor; not 5 because a plain-language user asking for a "报表" or "数据查询" would not obviously match, and not 3 because the domain keywords given are genuinely the ones target users say.

Distinctiveness Conflict Risk

It carves a clear niche as the declared single entry point ("唯一总入口…必须先经本 skill") and names the sibling skills it hands off to, so confusion risk with smart-search-tables / smart-ask-data / ontology-core is low. It is not 5 because claiming "凡与数据…相关的问题" (any data-related question) is very broad and could collide with other data skills outside this stack; not 3 because the explicit delegation boundaries keep overlap mostly theoretical.