Testing & Debugging Skills

Authors an EARS spec file (.yamlet.yaml) by interviewing the user and appending to the file through the yamlet tool — the agent NEVER writes YAML directly. Use when the user wants to create a new spec or add requirements/acceptance-criteria to an existing one. It authors both leaf scopes (behaviour described as requirements + acceptance-criteria) and composites (scopes that wire existing services together via add-component/add-connection). Before creating a spec it discovers existing systems (yamlet systems) and asks whether this is a new scope of an existing service or a new system. Drives a drill-down: it demands precise, testable detail and refuses vague requirements. IDs are generated by the script, never by the agent. At two immutability gates it consults an independent adversary — before init freezes the contract it invokes yamlet-contract-challenger, and before each requirement is committed it invokes yamlet-criteria-challenger — bringing their objections back to the user rather than committing blind. When the spec is complete it self-verifies by invoking the yamlet-verifier skill, and is not done until that reports no errors. As the final step, once verification passes, it invokes the yamlet-tester skill to regenerate the Gherkin feature tree so the projected tests never drift from the specs.

Adversarial gate used INSIDE the yamlet-author flow, immediately before yamlet init freezes a scope's contract. Given a proposed scope (system, topic, front, blast-radius, summary) and its input/output contract, it pokes holes: scope too broad to summarize in one sentence, duplicated or fragmented system, wrong trust boundary, missing or unused inputs/outputs, leaf-vs-composite misclassification. Invoked by yamlet-author at the pre-init gate; not a standalone tool.

Adversarial gate used INSIDE the yamlet-author flow, before a requirement and its acceptance-criteria are committed. Given a proposed requirement plus the EARS acceptance-criteria intended for it (patterns, clauses, shalls, placeholders/examples) and the scope's contract for context, it pokes holes: requirement bundling more than one capability, vague or untestable shalls, wrong EARS pattern, missing unwanted/if coverage on external fronts, unbound placeholders, contract inputs/outputs left unreferenced. Invoked by yamlet-author before each add-requirement; not a standalone tool.

Projects a directory of EARS specs (.yamlet.yaml) into a Gherkin .feature tree with yamlet tests, force-regenerating the whole tree every run so it can never drift from the specs. REQUIRES one argument — the specs source directory (e.g. /yamlet-tester specs); an optional second argument is the target directory, defaulting to /tests. Use as the closing step after a spec is authored/verified, or whenever specs change, to refresh the feature files. It is a DISCONNECTED projection: TARGET is yamlet-owned and wiped+rebuilt every run, holding .feature files only; the skill NEVER creates, edits, or deletes step definitions (which belong in the consumer's own directory) — it merely flags where they need attention. If no source directory is supplied it returns a usage error and does nothing.

Verifies an EARS spec file (.yamlet.yaml) against the format rules and reports violations with stable rule IDs. REQUIRES one argument — the path to the .yamlet.yaml file to verify (e.g. /yamlet-verifier specs/email.yamlet.yaml). Use for agent self-verification of a spec before relying on it. If no file path is supplied it returns a usage error and does nothing.