Content
78%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.
The body is an unusually strong piece of reference writing: entirely novel, non-inferable Maple specifics with executable JSON/SQL examples, explicit trap callouts, and a real verification feedback loop. Its main weakness is structural — ~616 lines of inlined reference material with no progressive disclosure into bundle files, plus some repetition of the query-boilerplate JSON blocks.
Suggestions
Split the self-contained reference tables into one-level-deep bundle files (e.g. references/panel-types.md, references/units.md, references/raw-sql.md, references/funnels-paths.md) and keep SKILL.md as a lean overview with the silent failures, verification loop, and links — this addresses the lowest-scoring dimension, progressive_disclosure.
De-duplicate the repeated addOns/boilerplate query JSON: show one full query draft once, then in later examples show only the fields that differ ({ 'addOns': … unchanged }, 'groupBy': ['service.name']) to reclaim ~100 lines of token budget.
Add a short explicit numbered build procedure at the top (choose panel type → pick data source kind → assemble or use add_dashboard_widget → read the inspect_chart_data verdict → fix and resubmit) so the workflow does not have to be reconstructed from section order.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is dense and trap-focused with no explanation of concepts Claude already knows — every line carries Maple-specific facts ('percent means a 0–1 fraction; percent_100 means 0–100', 'there is no last'). It falls short of 5 because the full addOns boilerplate query block is repeated near-verbatim in ~4 JSON examples (~40 lines each) and the groupBy/percent traps are restated across multiple sections, which could be tightened. It is above 3 because none of the content is generic filler or re-teaching. | 4 / 5 |
Actionability | Fully executable guidance: complete copy-paste JSON for each data-source kind, exact valid-token tables for aggregations and group-bys ('traces: count, avg_duration, p50_duration, p95_duration…'), the complete assembled-widget example, an executable ClickHouse SQL sample, and per-panel-type alias rules ('a DateTime bucket as the FIRST column (alias bucket)'). Score 5 rather than 4 because the examples are copy-paste ready and cover the common cases; not lower because there is no pseudocode or hand-waving. | 5 / 5 |
Workflow Clarity | There is a clear decision flow (prefer the simplified widgets array, reach for raw JSON only when needed), explicit validation checkpoints ('Call describe_warehouse_tables first', 'query_funnel to try a definition before pinning it'), and a feedback loop ('suspicious or broken means fix and resubmit'). Score 4 rather than 5 because the overall build sequence (choose panel type → choose data source → assemble → verify) is implied by section order rather than stated as an explicit ordered procedure with recovery steps; rather than 3 because verification is explicit and prominent, not merely implicit. | 4 / 5 |
Progressive Disclosure | The skill is a single ~616-line monolithic file with no references/, scripts/, or assets/ directories; large reference blocks (the panel-type table, the units table, the raw-SQL conventions, the funnel and paths specs) are inlined in SKILL.md when they clearly belong in separate one-level-deep reference files. Headers and navigation within the file are good, which keeps it above 2, but per the anchor, content that should be separate is inline with no external references at all, which prevents a 4. | 3 / 5 |
Total | 16 / 20 Passed |