openapi-ingestlisted

# openapi-ingest — the specification as requirement `us-ingest` takes a user story written for humans. This skill takes the other common entry point: a **formal, machine-readable specification**. Same chain afterwards — `istqb-design`, `prioritize`, `testbook-generate` all work unchanged, because the output shape is the same. ## Why this entry point earns its place The external campaign kept in `eval/external-application-2026-08-08/` found two real defects in a 75,000-star project by generating **from its documentation and never from its code**. The defect that mattered most was a one-character mismatch between what the documentation promised and what the implementation read. A suite written by looking at the code cannot find that class of defect: it copies the mistake. Most real APIs carry something better than prose — a schema. Enums, `required`, `minLength`, `maximum`, `pattern`, declared response codes: each is a promise stated precisely enough that a test condition falls out of it without interpretation. That is the opposite of the ambiguity tax paid on prose, and it is why this skill exists. ## The rule that makes it honest **A specification is a promise, not a fact.** It describes what the API is supposed to do; it is routinely out of date with what it does. Every condition derived here is of the form *"the spec promises X"* — never *"the API does X"*. Confirming or refuting is `contract-probe`'s job, and mixing the two is how a specification becomes a rubber sta