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.
A well-built mentoring skill body: dense decision tables, explicit stop conditions and output caps, a concrete worked example, and a clean one-level reference split. The main gaps are deliberate doctrinal repetition, missing anchor cost figures/sample configs for the cost and reuse-first guidance, and no error-recovery loop for conflicting requirements.
Suggestions
State the firmware-reuse-first doctrine once (Core style rules) and cross-reference it from section 3 and Anti-Patterns instead of restating it, trimming the same treatment for the port-forward warning.
Add anchor cost figures (either an example range table inline or in references/hardware-selection.md) and a minimal ESPHome YAML snippet so the time/cost and reuse-first guidance has concrete numbers to cite.
Add an explicit recovery path when constraints conflict or MVP exit criteria fail — e.g., re-ask the binding question and re-recommend — to close the workflow's feedback-loop gap.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body assumes Claude's competence (no what-is-an-MCU padding) and uses dense decision tables and terse imperatives, but the reuse-first doctrine is stated three times ("Firmware that already exists beats firmware to be written" in Core style rules, "a maintained ready-made firmware usually exists" in section 3, "Writing firmware from scratch before checking for a maintained ready-made project" in Anti-Patterns) and the port-forward warning likewise recurs. This fits the 4 anchor's "minor instances of over-explanation that could be trimmed" rather than the 5 anchor's every-token-earns-its-place. | 4 / 5 |
Actionability | Highly concrete for an instruction-only skill: named platforms in decision tables ("ESP32 DevKit", "nRF52 / STM32L", "STM32 Nucleo"), named ready-made firmware ("ESPHome, Meshtastic, Tasmota, WLED"), a worked example with named parts ("$2 DS18B20 or SHT31"), and enumerated questions with exact output caps. Not 5: "Give ranges only, sourced from LCSC / Digi-Key / local stores" provides no anchor cost figures anywhere in the bundle, and no sample ESPHome YAML is shown despite "a 20-line YAML file" being the touted path — minor gaps characteristic of the 4 anchor. | 4 / 5 |
Workflow Clarity | The process is clearly sequenced and gated: questions one at a time ("ask only what is still missing"), a numbered 6-step recommendation process, output-format caps with "Drop it when" conditions, MVP exit criteria, and "stop after MVP unless asked" stop conditions. Not 5: the top anchor's feedback loops for error recovery are absent — there is no explicit re-ask/re-recommend loop for conflicting constraints (e.g., budget vs. buy-ability) or failed MVP exit criteria; not 3 because checkpoints and stop conditions are explicit and frequent. | 4 / 5 |
Progressive Disclosure | The single reference is well-signaled with purpose twice ("Datasheet-level facts behind the tables below... live in references/hardware-selection.md — cite it when a recommendation gets a 'why that board?' follow-up"), the file exists and contains exactly the cited content (family power figures, PIO, toolchains, power-budget arithmetic), and it is one level deep with no nesting. Policy stays in SKILL.md while datasheet detail is split out — a clear match to the 5 anchor. | 5 / 5 |
Total | 17 / 20 Passed |