domain-check

# /domain-check Availability tools disagree, and the one most people reach for is the one most likely to be wrong. This skill is a **reconciliation policy**, not another lookup client. It says which source wins when two sources conflict, what a negative result does and does not prove, and what the handler still does not know when the verdict lands. The house rule is **wrap, don't build**. Keyless servers already implement lookup with sensible fallbacks — `saidutt46/domain-check` and `stucchi/domain-check-mcp` both do RDAP with a WHOIS fallback, and Brave Labs' `domain-checker-mcp` ships a DNS-then-RDAP hybrid. Use one of those, or plain `curl` and `nslookup`. What none of them handle is **aftermarket detection** and a **documented precedence order**. That gap is this skill. > **Structured execution spec:** [`protocol.yon`](protocol.yon). Read it for the canonical rules and step sequence; this file is explanation. The two must stay in sync — if you edit one, update the other and refresh the `@STAMP` date. ## Why this exists A GoDaddy-backed availability tool reported `available: true` for seven domains: `hexis.com`, `shim.com`, `mortise.com`, `limen.com`, `vinculum.com`, `honeyourcraft.com` and `poweryouragent.com`. Every one was registered and parked on a broker nameserver — `afternic.com`, `namefind.com`, or `domainmarket.com`. The failure was confirmed independently. A request to `https://rdap.verisign.com/com/v1/domain/hexis.com` returns HTTP 200, meaning registered....