interface-factslisted

Establish a fact about an external interface - a CLI flag, an API field, a model id, a price, a limit, a version - by fetching the vendor's current documentation instead of recalling it. Use before writing code, a design note, or any claim that depends on how a third-party tool behaves, and whenever a repo document already asserts such a behaviour.
niksavis/basicly · ★ 0 · AI & Automation · score 72

Install: claude install-skill niksavis/basicly

# Interface Facts A model's knowledge of an external interface is a snapshot of whenever it was trained, and vendors ship. So **an external interface fact is unverified until it is fetched**. The cost is asymmetric: a wrong fact about our own code fails a gate, a wrong fact about someone else's interface gets committed as prose and is believed for months. Covers CLI flags and output formats, API fields and endpoints, model ids, context windows, token accounting, pricing, rate limits, config schemas, and version-gated behaviour. ## The order of evidence 1. **Our own code that already touches the interface.** If an adapter, parser or hook reads the thing, that code is the evidence — it was written against a real probe and it is under test. 2. **The installed binary, interrogated.** `--help`, `--version`, a `--dry-run`, an invalid flag whose error names the valid set. This outranks documentation when the question is what *this* version accepts: the docs describe a release, the binary on the path is the one the command will run. 3. **The vendor's current documentation**, fetched now. 4. **The vendor's changelog**, which dates the change. 5. **The vendor's source or issue tracker**, where a documented feature that does not work gets contradicted. 6. **Third-party writing** — weakest, never sufficient alone. A landing page or feature grid is marketing. A README is a c