Content
71%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-structured orchestration skill: clear step sequencing with routing checkpoints, concrete (if placeholder-heavy) command forms, and exemplary progressive disclosure across verified reference files. Its main weaknesses are systematic repetition of the delegation and routing constraints, which inflate token cost without adding information, and the absence of error-recovery guidance for failed query executions.
Suggestions
State the ontology-core delegation rule once (e.g., in the 调用方式 section with the call-chain diagram) and remove the repeated 'Never 直接执行' formulations from the sub-skill table, command-shape section, and elsewhere; the duplicated no-token/Metric-routing passages (lines 59/132 and description/line 73) can likewise be consolidated.
Include one complete, copy-paste-ready example inline — e.g., a full `bkn object-type query` call with a realistic '<filter-json>' value and a populated `properties` payload — so the common single-table path is executable without opening a reference file.
Add a brief error-recovery step after step 4 (e.g., what to do when `dataview query` returns an error or an unexpected schema — re-run schema discovery, adjust SQL, re-execute) to close the workflow's feedback loop.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is domain-specific throughout (no concepts Claude already knows), but key constraints are repeated systematically: the ontology-core delegation rule appears in the call-chain diagram, the sub-skill table, the command-shape section, and again in references; the no-token statement ("不出现 --token / auth.token / Authorization") appears twice (lines 59 and 132), as does the Metric-routing exclusion. This fits 'mostly efficient but includes some unnecessary explanation or could be tightened'; not 4 because the redundancy is structural (whole duplicated passages), not minor. | 3 / 5 |
Actionability | Concrete command forms are given — "bkn object-type list <kn-id>", "dataview query <dataview-id> --sql \"...\"", and the full properties payload shape '{"_instance_identities":[{...}],"properties":[...]}' — plus the mandatory "--user-id <accountId>" placement rule. Not 5 because '<filter-json>' and '{...}' elide actual JSON bodies and no complete worked command with realistic values appears inline (those are deferred to references). | 4 / 5 |
Workflow Clarity | The 主流程 checklist sequences 5 steps with an explicit either/or routing checkpoint (3a 逻辑属性 vs 3b SQL, "不可混用"), a schema-before-SQL anti-hallucination gate ("Schema 发现先于取数…防止 SQL 幻觉"), SELECT/WITH-only enforcement, an empty-result rule, and hard output constraints. Not 5 because there is no error-recovery feedback loop for a failing or malformed dataview query result. | 4 / 5 |
Progressive Disclosure | The body is a true overview: a per-step table maps each pipeline step to one reference file, and all four referenced files (kn-resolve.md, schema-discovery.md, sql-execute.md, tool-examples.md) plus config.json exist and are one level deep with no further nesting. Detailed command syntax and end-to-end examples are correctly split out of SKILL.md, matching the 'clear overview with well-signaled one-level-deep references' anchor. | 5 / 5 |
Total | 16 / 20 Passed |