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 dense, highly actionable CLI orchestration guide with strong confirmation and validation workflows (confirmation gates, dry-run previews, diff checkpoints, bounded retries) and a well-verified, clearly signaled reference tree covering 20+ DingTalk products. Its main weaknesses are repeated restatements of the routing and confirmation doctrine plus inlined schema-contract meta-documentation, which inflate token cost without proportional guidance gains.
Suggestions
Consolidate the routing doctrine (known intent → route via product reference, read one leaf Schema, verify flags with --help) — currently restated in "Shortcut 与原子命令的使用原则", the "Shortcut 总览" intro, the "命令发现" intro, and "已知命令路径例外" — into one authoritative section and cross-reference it from the others.
Move the Schema contract internals (ContractFinal.Identity binding, ToolSpec full/compact projection semantics, the --compact field whitelist) into global-reference.md or a dedicated schema reference file, keeping only the layered query examples and boundary table in the body.
State the `--yes` confirmation rule once in the 危险操作确认 section and reference it from MUST DO and the shortcut principles instead of repeating the full rule four times.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Almost every line carries novel operational rules rather than concepts Claude already knows, but the core routing doctrine ("先按产品参考、意图表和 recipe 路由...读一次 leaf 窄 Schema...用 --help 核对当前 Cobra 接受的 flags") is restated in "Shortcut 与原子命令的使用原则", the "Shortcut 总览" intro, the "命令发现" section intro, and "已知命令路径例外", and the `--yes` confirmation rule recurs in MUST DO, shortcut principles, 危险操作确认, and 确认门禁. Fits "mostly efficient but includes some unnecessary explanation or could be tightened" — not 2 (no concept-teaching padding or fluff) and not 4 (the repetition exceeds minor). | 3 / 5 |
Actionability | Guidance is copy-paste executable throughout: `dws schema "calendar event create" --compact`, `dws event consume user_card_action_triggered --flatten -f ndjson`, `dws auth login --intl --device`, `dws schema --cli-path "<service> +<verb>" --compact --format json`, plus a concrete JSONC leaf-schema example with real fields (effect/risk/confirmation/constraints). Matches "fully executable; copy-paste ready code or commands; specific examples cover the common cases". | 5 / 5 |
Workflow Clarity | Sequenced core flow (URL 预检 → 意图分类 → 歧义追问 → 精准产品映射 → 最小化读取), a numbered confirmation flow (展示操作摘要 → 用户明确确认 → 加 --yes), a structured confirmation_required retry protocol with --dry-run preview as an explicit validation checkpoint, bounded retry driven by server retry semantics ("只有明确 retryable=true 时才按服务端节奏做一次有界重试"), and whiteboard render/+diff validation gates before +update. This matches "clear sequence with explicit validation steps; feedback loops for error recovery"; the destructive/batch cap does not apply because confirmation, diff, and dry-run validation are pervasive. | 5 / 5 |
Progressive Disclosure | The body acts as a router pushing per-product detail into 100+ real reference files, all verified present and well-signaled with per-file purpose descriptions (产品总览 table, 详细参考 list, numbered best_practices scenarios). However, some chains run two levels deep (products/aitable.md → products/aitable/*.md chapters; doc.md → doc/ subfiles), and ~100 lines of CLI contract meta-detail (ContractFinal.Identity, ToolSpec full/compact projection, the --compact field whitelist) are inlined in the body where they could live in a reference file. Fits "good structure; most content is appropriately placed; minor organization gaps" rather than the 5 anchor's clean one-level-deep split. | 4 / 5 |
Total | 17 / 20 Passed |