canonical-test-spec

Generate a deterministic, framework-independent canonical test specification from hardware chip documentation.

Updated Mar 15, 2026
One-click install
npx skills add https://github.com/mohankumargupta/skills --skill canonical-test-spec-mohankumargupta
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: canonical-test-spec
Source: https://github.com/mohankumargupta/skills/tree/main/canonical-test-spec
Command: npx skills add https://github.com/mohankumargupta/skills --skill canonical-test-spec-mohankumargupta

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Hardware test artifacts (simulator fixtures, firmware configs, integration tests) are often generated independently, causing inconsistent values and behavior. This Skill produces a single Canonical Test Specification from a chip's ESPHome component source and docs, acting as the one source of truth for all downstream code generation. ## Core Features & Use Cases - Canonical Spec Generation: Produces a minimal, deterministic, implementation-independent YAML-style specification describing observable device behavior (observables, units, defaults, presentation templates). - Hallucination Prevention: Requires every value to trace to an authoritative source (datasheet, ESPHome component source, reference driver) and mandates status: unknown instead of guessing. - Single Source of Truth for Defaults: Defines one default value per observable consumed by both simulator chips and test harnesses, preventing silent simulation-time mismatches. - Use Case: Given the ESPHome component source and docs for a TMP102 sensor, generate test_spec_tmp102.md so downstream skills can build a Wokwi custom chip and a serial-output test harness that agree on the emitted and asserted temperature value. ## Quick Start Generate a canonical test specification for the TMP102 device using the ESPHome component files in the outputs directory.

Frequently Asked Questions about canonical-test-spec

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I generate a canonical test specification for a hardware sensor?▼

Provide the ESPHome component name, its documentation markdown, component source code, and the device spec file in the outputs directory. The skill produces a test_spec_<device>.md file describing observables, defaults, assumptions, and presentation templates.

What is a Canonical Test Specification in embedded testing?▼

It is a deterministic, framework-independent document describing the smallest observable scenario demonstrating a device's primary capability. It serves as the single source of truth from which simulator fixtures, firmware configs, and integration tests are generated.

Does the canonical test spec depend on ESPHome or Wokwi?▼

No. The specification is explicitly framework-independent and excludes ESPHome, Wokwi, protocol timing, and driver details. It describes only observable behavior, leaving framework-specific generation to downstream skills.

Why must default values come from the spec instead of each generator?▼

Both the simulated chip and the test harness read the same default field as emitted value and asserted ground truth. Independently chosen defaults only conflict at simulation time, producing tests that always pass or always fail for invisible reasons.

What happens when device information cannot be determined from sources?▼

The skill emits status: unknown rather than guessing. Every value must trace to a datasheet, hardware specification, reference driver, ESPHome component source, or explicit user instruction.