api-and-interface-design
Guides stable API and interface design. Use when designing APIs, module boundaries, or any public interface. Use when creating REST or GraphQL endpoints, defining type contracts between modules, or establishing boundaries between frontend and backend.
Install
With your agent
Install OMGSkills skill "addyosmani/agent-skills:skills/api-and-interface-design" into this agent's normal skills directory: call the OMGSkills MCP get_install_plan tool for your agent and run the script it returns (it installs only the pinned commit and verifies SKILL.md), and stop if MCP or the pin is unavailable. Do not overwrite or change existing skills without asking me.
Manual command
git clone https://github.com/addyosmani/agent-skills /tmp/agent-skills && ln -s /tmp/agent-skills/skills/api-and-interface-design ~/.claude/skills/api-and-interface-designFrom README
API and Interface Design Overview Design stable, well-documented interfaces that are hard to misuse. Good interfaces make the right thing easy and the wrong thing hard. This applies to REST APIs, GraphQL schemas, module boundaries, component props, and any surface where one piece of code talks to another. When to Use Designing new API endpoints Defining module boundaries or contracts between teams Creating component prop interfaces Establishing database schema that informs API shape Changing existing public interfaces Core Principles Hyrum's Law With a sufficient number of users of an API, all observable behaviors of your system will be depended on by somebody, regardless of what you promise in the contract. This means: every public behavior — including undocumented quirks, error message text, timing, and ordering — becomes a de facto contract once users depend on it. Design implications: Be intentional about what you expose. Every observable behavior is a potential commitment.