What problem does it solve? Building UI pages against the Helios Terminology Server (HTS) requires knowing its 42 routes, FHIR content-negotiation quirks, OperationOutcome error model, and which operations lack any existing client in the HFS workspace. This Skill consolidates that knowledge so UI authors do not misrender errors, misuse GET parameters, or build affordances for unimplemented features. ## Core Features & Use Cases - Complete route and operation reference: Covers all 42 HTS routes ($lookup, $validate-code, $expand, $subsumes, $translate, $closure, $batch-validate-code, CRUD, /import, /metadata, /health, /metrics) with body shapes, content negotiation, and status-code mappings. - UI integration patterns: Documents the server-side proxy pattern via HFS_TERMINOLOGY_SERVER, htmx fragment conventions, i18n key rules, tenant/locale propagation, and OperationOutcome rendering for /ui/hts/* pages under crates/ui. - Gap and drift awareness: Flags advertised-but-unimplemented features ($versions, includeDefinition, _sort, accurate _total) and auth gaps so reviewers catch mismatches between UI and server reality. - Use Case: When adding a ValueSet expansion page, use this Skill to wire the POST /ValueSet/{id}/$expand call through the existing TerminologyClient, render 422 too-costly responses with an X-TOO-COSTLY-THRESHOLD escape hatch, and pass the PR verification checklist. ## Quick Start Use the hts-api-skill to plan and implement a new /ui/hts/value-sets expansion page that proxies HTS $expand calls server-side and renders OperationOutcome errors correctly.
