loom-api-and-interface-designlisted

# loom-api-and-interface-design API and interface design is a spec-first playbook for shared contracts. It defines the contract before implementation, checks compatibility and error semantics, and routes execution through tickets, evidence, and audit. If consumers, data shape, compatibility promise, permission boundary, or domain model are unclear, stay in design shaping before implementation. ## Loom Routing Common routes use these Loom skills for durable records or follow-up workflow: `loom-specs`, `loom-research`, `loom-tickets`, `loom-ralph`, `loom-evidence`, `loom-audit`, `loom-constitution`, and `loom-knowledge`. Follow any named Loom skill fully. This playbook adds workflow pressure; it does not shorten target-skill requirements. ## Use This Playbook When Use this playbook when designing or changing: - REST, GraphQL, RPC, event, webhook, or CLI interfaces - module boundaries or exported functions - component props or design-system contracts - data shapes, file formats, records, or worker handoffs - frontend/backend contracts - public behavior that consumers may depend on ## Route Use this route: ```text consumer -> contract -> compatibility -> implement -> evidence -> audit ``` ## Consumer Identify the consumers: - users, callers, clients, components, services, workers, agents, or future records - existing consumers and their current assumptions - domain model and state relationships the interface should expose or hide - compatibility expectations - unsu