[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6J1QPDBKFKW8SFSBC9MB4ZF":3,"skill-same:01M6J1QPDBKFKW8SFSBC9MB4ZF":87},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":40,"publishedAt":59,"linkOnly":60,"markdownContent":61,"markdownBody":62,"frontMatter":63,"refName":64,"commitSha":65,"skillDirectory":66,"forksCount":67,"repositoryHtmlUrl":68,"repositoryHomepageUrl":69,"ownerHtmlUrl":70,"ownerBlogUrl":6,"ownerDescription":71,"updatedAt":72,"install":73,"resources":86},"01M6J1QPDBKFKW8SFSBC9MB4ZF","api-and-interface-design",null,"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.","sampleXbro\u002Fagentsmesh","sampleXbro","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F55853222?v=4","01M6J1A11VAS9QEE92CHHMBCKC","Serhii Zhabskyi","01M6J1A16FCGNMMABYE0P6SNTF",28,"MIT","https:\u002F\u002Fgithub.com\u002FsampleXbro\u002Fagentsmesh\u002Fblob\u002Fmaster\u002F.agentsmesh\u002Fpacks\u002Faddyosmani-agent-skills-pack\u002Fskills\u002Fapi-and-interface-design\u002FSKILL.md",[18,23,26,29,34,37],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":30,"categoryName":31,"taxonomyType":32,"taxonomyTypeDesc":33},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",{"categoryNo":35,"categoryName":36,"taxonomyType":32,"taxonomyTypeDesc":33},"01JBSEEDCAT000000000000032","设计师",{"categoryNo":38,"categoryName":39,"taxonomyType":32,"taxonomyTypeDesc":33},"01JBSEEDCAT000000000000037","律师与法务",[41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58],"design","interface","interface design","api and interface design","api","public","GraphQL","use","backend","modules","endpoints","contracts","module","type","guides","designing apis","REST","frontend","2026-11-10 10:12:30",false,"---\nname: api-and-interface-design\ndescription: 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.\n---\n\n# API and Interface Design\n\n## Overview\n\nDesign 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.\n\n## When to Use\n\n- Designing new API endpoints\n- Defining module boundaries or contracts between teams\n- Creating component prop interfaces\n- Establishing database schema that informs API shape\n- Changing existing public interfaces\n\n## Core Principles\n\n### Hyrum's Law\n\n> 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.\n\nThis 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:\n\n- **Be intentional about what you expose.** Every observable behavior is a potential commitment.\n- **Don't leak implementation details.** If users can observe it, they will depend on it.\n- **Plan for deprecation at design time.** See `deprecation-and-migration` for how to safely remove things users depend on.\n- **Tests are not enough.** Even with perfect contract tests, Hyrum's Law means \"safe\" changes can break real users who depend on undocumented behavior.\n\n### The One-Version Rule\n\nAvoid forcing consumers to choose between multiple versions of the same dependency or API. Diamond dependency problems arise when different consumers need different versions of the same thing. Design for a world where only one version exists at a time — extend rather than fork.\n\n### 1. Contract First\n\nDefine the interface before implementing it. The contract is the spec — implementation follows.\n\n```typescript\n\u002F\u002F Define the contract first\ninterface TaskAPI {\n  \u002F\u002F Creates a task and returns the created task with server-generated fields\n  createTask(input: CreateTaskInput): Promise\u003CTask>;\n\n  \u002F\u002F Returns paginated tasks matching filters\n  listTasks(params: ListTasksParams): Promise\u003CPaginatedResult\u003CTask>>;\n\n  \u002F\u002F Returns a single task or throws NotFoundError\n  getTask(id: string): Promise\u003CTask>;\n\n  \u002F\u002F Partial update — only provided fields change\n  updateTask(id: string, input: UpdateTaskInput): Promise\u003CTask>;\n\n  \u002F\u002F Idempotent delete — succeeds even if already deleted\n  deleteTask(id: string): Promise\u003Cvoid>;\n}\n```\n\n### 2. Consistent Error Semantics\n\nPick one error strategy and use it everywhere:\n\n```typescript\n\u002F\u002F REST: HTTP status codes + structured error body\n\u002F\u002F Every error response follows the same shape\ninterface APIError {\n  error: {\n    code: string;        \u002F\u002F Machine-readable: \"VALIDATION_ERROR\"\n    message: string;     \u002F\u002F Human-readable: \"Email is required\"\n    details?: unknown;   \u002F\u002F Additional context when helpful\n  };\n}\n\n\u002F\u002F Status code mapping\n\u002F\u002F 400 → Client sent invalid data\n\u002F\u002F 401 → Not authenticated\n\u002F\u002F 403 → Authenticated but not authorized\n\u002F\u002F 404 → Resource not found\n\u002F\u002F 409 → Conflict (duplicate, version mismatch)\n\u002F\u002F 422 → Validation failed (semantically invalid)\n\u002F\u002F 500 → Server error (never expose internal details)\n```\n\n**Don't mix patterns.** If some endpoints throw, others return null, and others return `{ error }` — the consumer can't predict behavior.\n\n### 3. Validate at Boundaries\n\nTrust internal code. Validate at system edges where external input enters:\n\n```typescript\n\u002F\u002F Validate at the API boundary\napp.post('\u002Fapi\u002Ftasks', async (req, res) => {\n  const result = CreateTaskSchema.safeParse(req.body);\n  if (!result.success) {\n    return res.status(422).json({\n      error: {\n        code: 'VALIDATION_ERROR',\n        message: 'Invalid task data',\n        details: result.error.flatten(),\n      },\n    });\n  }\n\n  \u002F\u002F After validation, internal code trusts the types\n  const task = await taskService.create(result.data);\n  return res.status(201).json(task);\n});\n```\n\nWhere validation belongs:\n- API route handlers (user input)\n- Form submission handlers (user input)\n- External service response parsing (third-party data -- **always treat as untrusted**)\n- Environment variable loading (configuration)\n\n> **Third-party API responses are untrusted data.** Validate their shape and content before using them in any logic, rendering, or decision-making. A compromised or misbehaving external service can return unexpected types, malicious content, or instruction-like text.\n\nWhere validation does NOT belong:\n- Between internal functions that share type contracts\n- In utility functions called by already-validated code\n- On data that just came from your own database\n\n### 4. Prefer Addition Over Modification\n\nExtend interfaces without breaking existing consumers:\n\n```typescript\n\u002F\u002F Good: Add optional fields\ninterface CreateTaskInput {\n  title: string;\n  description?: string;\n  priority?: 'low' | 'medium' | 'high';  \u002F\u002F Added later, optional\n  labels?: string[];                       \u002F\u002F Added later, optional\n}\n\n\u002F\u002F Bad: Change existing field types or remove fields\ninterface CreateTaskInput {\n  title: string;\n  \u002F\u002F description: string;  \u002F\u002F Removed — breaks existing consumers\n  priority: number;         \u002F\u002F Changed from string — breaks existing consumers\n}\n```\n\n### 5. Predictable Naming\n\n| Pattern | Convention | Example |\n|---------|-----------|---------|\n| REST endpoints | Plural nouns, no verbs | `GET \u002Fapi\u002Ftasks`, `POST \u002Fapi\u002Ftasks` |\n| Query params | camelCase | `?sortBy=createdAt&pageSize=20` |\n| Response fields | camelCase | `{ createdAt, updatedAt, taskId }` |\n| Boolean fields | is\u002Fhas\u002Fcan prefix | `isComplete`, `hasAttachments` |\n| Enum values | UPPER_SNAKE | `\"IN_PROGRESS\"`, `\"COMPLETED\"` |\n\n## REST API Patterns\n\n### Resource Design\n\n```\nGET    \u002Fapi\u002Ftasks              → List tasks (with query params for filtering)\nPOST   \u002Fapi\u002Ftasks              → Create a task\nGET    \u002Fapi\u002Ftasks\u002F:id          → Get a single task\nPATCH  \u002Fapi\u002Ftasks\u002F:id          → Update a task (partial)\nDELETE \u002Fapi\u002Ftasks\u002F:id          → Delete a task\n\nGET    \u002Fapi\u002Ftasks\u002F:id\u002Fcomments → List comments for a task (sub-resource)\nPOST   \u002Fapi\u002Ftasks\u002F:id\u002Fcomments → Add a comment to a task\n```\n\n### Pagination\n\nPaginate list endpoints:\n\n```typescript\n\u002F\u002F Request\nGET \u002Fapi\u002Ftasks?page=1&pageSize=20&sortBy=createdAt&sortOrder=desc\n\n\u002F\u002F Response\n{\n  \"data\": [...],\n  \"pagination\": {\n    \"page\": 1,\n    \"pageSize\": 20,\n    \"totalItems\": 142,\n    \"totalPages\": 8\n  }\n}\n```\n\n### Filtering\n\nUse query parameters for filters:\n\n```\nGET \u002Fapi\u002Ftasks?status=in_progress&assignee=user123&createdAfter=2025-01-01\n```\n\n### Partial Updates (PATCH)\n\nAccept partial objects — only update what's provided:\n\n```typescript\n\u002F\u002F Only title changes, everything else preserved\nPATCH \u002Fapi\u002Ftasks\u002F123\n{ \"title\": \"Updated title\" }\n```\n\n## TypeScript Interface Patterns\n\n### Use Discriminated Unions for Variants\n\n```typescript\n\u002F\u002F Good: Each variant is explicit\ntype TaskStatus =\n  | { type: 'pending' }\n  | { type: 'in_progress'; assignee: string; startedAt: Date }\n  | { type: 'completed'; completedAt: Date; completedBy: string }\n  | { type: 'cancelled'; reason: string; cancelledAt: Date };\n\n\u002F\u002F Consumer gets type narrowing\nfunction getStatusLabel(status: TaskStatus): string {\n  switch (status.type) {\n    case 'pending': return 'Pending';\n    case 'in_progress': return `In progress (${status.assignee})`;\n    case 'completed': return `Done on ${status.completedAt}`;\n    case 'cancelled': return `Cancelled: ${status.reason}`;\n  }\n}\n```\n\n### Input\u002FOutput Separation\n\n```typescript\n\u002F\u002F Input: what the caller provides\ninterface CreateTaskInput {\n  title: string;\n  description?: string;\n}\n\n\u002F\u002F Output: what the system returns (includes server-generated fields)\ninterface Task {\n  id: string;\n  title: string;\n  description: string | null;\n  createdAt: Date;\n  updatedAt: Date;\n  createdBy: string;\n}\n```\n\n### Use Branded Types for IDs\n\n```typescript\ntype TaskId = string & { readonly __brand: 'TaskId' };\ntype UserId = string & { readonly __brand: 'UserId' };\n\n\u002F\u002F Prevents accidentally passing a UserId where a TaskId is expected\nfunction getTask(id: TaskId): Promise\u003CTask> { ... }\n```\n\n## Common Rationalizations\n\n| Rationalization | Reality |\n|---|---|\n| \"We'll document the API later\" | The types ARE the documentation. Define them first. |\n| \"We don't need pagination for now\" | You will the moment someone has 100+ items. Add it from the start. |\n| \"PATCH is complicated, let's just use PUT\" | PUT requires the full object every time. PATCH is what clients actually want. |\n| \"We'll version the API when we need to\" | Breaking changes without versioning break consumers. Design for extension from the start. |\n| \"Nobody uses that undocumented behavior\" | Hyrum's Law: if it's observable, somebody depends on it. Treat every public behavior as a commitment. |\n| \"We can just maintain two versions\" | Multiple versions multiply maintenance cost and create diamond dependency problems. Prefer the One-Version Rule. |\n| \"Internal APIs don't need contracts\" | Internal consumers are still consumers. Contracts prevent coupling and enable parallel work. |\n\n## Red Flags\n\n- Endpoints that return different shapes depending on conditions\n- Inconsistent error formats across endpoints\n- Validation scattered throughout internal code instead of at boundaries\n- Breaking changes to existing fields (type changes, removals)\n- List endpoints without pagination\n- Verbs in REST URLs (`\u002Fapi\u002FcreateTask`, `\u002Fapi\u002FgetUsers`)\n- Third-party API responses used without validation or sanitization\n\n## Verification\n\nAfter designing an API:\n\n- [ ] Every endpoint has typed input and output schemas\n- [ ] Error responses follow a single consistent format\n- [ ] Validation happens at system boundaries only\n- [ ] List endpoints support pagination\n- [ ] New fields are additive and optional (backward compatible)\n- [ ] Naming follows consistent conventions across all endpoints\n- [ ] API documentation or types are committed alongside the implementation\n","# API and Interface Design\n\n## Overview\n\nDesign 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.\n\n## When to Use\n\n- Designing new API endpoints\n- Defining module boundaries or contracts between teams\n- Creating component prop interfaces\n- Establishing database schema that informs API shape\n- Changing existing public interfaces\n\n## Core Principles\n\n### Hyrum's Law\n\n> 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.\n\nThis 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:\n\n- **Be intentional about what you expose.** Every observable behavior is a potential commitment.\n- **Don't leak implementation details.** If users can observe it, they will depend on it.\n- **Plan for deprecation at design time.** See `deprecation-and-migration` for how to safely remove things users depend on.\n- **Tests are not enough.** Even with perfect contract tests, Hyrum's Law means \"safe\" changes can break real users who depend on undocumented behavior.\n\n### The One-Version Rule\n\nAvoid forcing consumers to choose between multiple versions of the same dependency or API. Diamond dependency problems arise when different consumers need different versions of the same thing. Design for a world where only one version exists at a time — extend rather than fork.\n\n### 1. Contract First\n\nDefine the interface before implementing it. The contract is the spec — implementation follows.\n\n```typescript\n\u002F\u002F Define the contract first\ninterface TaskAPI {\n  \u002F\u002F Creates a task and returns the created task with server-generated fields\n  createTask(input: CreateTaskInput): Promise\u003CTask>;\n\n  \u002F\u002F Returns paginated tasks matching filters\n  listTasks(params: ListTasksParams): Promise\u003CPaginatedResult\u003CTask>>;\n\n  \u002F\u002F Returns a single task or throws NotFoundError\n  getTask(id: string): Promise\u003CTask>;\n\n  \u002F\u002F Partial update — only provided fields change\n  updateTask(id: string, input: UpdateTaskInput): Promise\u003CTask>;\n\n  \u002F\u002F Idempotent delete — succeeds even if already deleted\n  deleteTask(id: string): Promise\u003Cvoid>;\n}\n```\n\n### 2. Consistent Error Semantics\n\nPick one error strategy and use it everywhere:\n\n```typescript\n\u002F\u002F REST: HTTP status codes + structured error body\n\u002F\u002F Every error response follows the same shape\ninterface APIError {\n  error: {\n    code: string;        \u002F\u002F Machine-readable: \"VALIDATION_ERROR\"\n    message: string;     \u002F\u002F Human-readable: \"Email is required\"\n    details?: unknown;   \u002F\u002F Additional context when helpful\n  };\n}\n\n\u002F\u002F Status code mapping\n\u002F\u002F 400 → Client sent invalid data\n\u002F\u002F 401 → Not authenticated\n\u002F\u002F 403 → Authenticated but not authorized\n\u002F\u002F 404 → Resource not found\n\u002F\u002F 409 → Conflict (duplicate, version mismatch)\n\u002F\u002F 422 → Validation failed (semantically invalid)\n\u002F\u002F 500 → Server error (never expose internal details)\n```\n\n**Don't mix patterns.** If some endpoints throw, others return null, and others return `{ error }` — the consumer can't predict behavior.\n\n### 3. Validate at Boundaries\n\nTrust internal code. Validate at system edges where external input enters:\n\n```typescript\n\u002F\u002F Validate at the API boundary\napp.post('\u002Fapi\u002Ftasks', async (req, res) => {\n  const result = CreateTaskSchema.safeParse(req.body);\n  if (!result.success) {\n    return res.status(422).json({\n      error: {\n        code: 'VALIDATION_ERROR',\n        message: 'Invalid task data',\n        details: result.error.flatten(),\n      },\n    });\n  }\n\n  \u002F\u002F After validation, internal code trusts the types\n  const task = await taskService.create(result.data);\n  return res.status(201).json(task);\n});\n```\n\nWhere validation belongs:\n- API route handlers (user input)\n- Form submission handlers (user input)\n- External service response parsing (third-party data -- **always treat as untrusted**)\n- Environment variable loading (configuration)\n\n> **Third-party API responses are untrusted data.** Validate their shape and content before using them in any logic, rendering, or decision-making. A compromised or misbehaving external service can return unexpected types, malicious content, or instruction-like text.\n\nWhere validation does NOT belong:\n- Between internal functions that share type contracts\n- In utility functions called by already-validated code\n- On data that just came from your own database\n\n### 4. Prefer Addition Over Modification\n\nExtend interfaces without breaking existing consumers:\n\n```typescript\n\u002F\u002F Good: Add optional fields\ninterface CreateTaskInput {\n  title: string;\n  description?: string;\n  priority?: 'low' | 'medium' | 'high';  \u002F\u002F Added later, optional\n  labels?: string[];                       \u002F\u002F Added later, optional\n}\n\n\u002F\u002F Bad: Change existing field types or remove fields\ninterface CreateTaskInput {\n  title: string;\n  \u002F\u002F description: string;  \u002F\u002F Removed — breaks existing consumers\n  priority: number;         \u002F\u002F Changed from string — breaks existing consumers\n}\n```\n\n### 5. Predictable Naming\n\n| Pattern | Convention | Example |\n|---------|-----------|---------|\n| REST endpoints | Plural nouns, no verbs | `GET \u002Fapi\u002Ftasks`, `POST \u002Fapi\u002Ftasks` |\n| Query params | camelCase | `?sortBy=createdAt&pageSize=20` |\n| Response fields | camelCase | `{ createdAt, updatedAt, taskId }` |\n| Boolean fields | is\u002Fhas\u002Fcan prefix | `isComplete`, `hasAttachments` |\n| Enum values | UPPER_SNAKE | `\"IN_PROGRESS\"`, `\"COMPLETED\"` |\n\n## REST API Patterns\n\n### Resource Design\n\n```\nGET    \u002Fapi\u002Ftasks              → List tasks (with query params for filtering)\nPOST   \u002Fapi\u002Ftasks              → Create a task\nGET    \u002Fapi\u002Ftasks\u002F:id          → Get a single task\nPATCH  \u002Fapi\u002Ftasks\u002F:id          → Update a task (partial)\nDELETE \u002Fapi\u002Ftasks\u002F:id          → Delete a task\n\nGET    \u002Fapi\u002Ftasks\u002F:id\u002Fcomments → List comments for a task (sub-resource)\nPOST   \u002Fapi\u002Ftasks\u002F:id\u002Fcomments → Add a comment to a task\n```\n\n### Pagination\n\nPaginate list endpoints:\n\n```typescript\n\u002F\u002F Request\nGET \u002Fapi\u002Ftasks?page=1&pageSize=20&sortBy=createdAt&sortOrder=desc\n\n\u002F\u002F Response\n{\n  \"data\": [...],\n  \"pagination\": {\n    \"page\": 1,\n    \"pageSize\": 20,\n    \"totalItems\": 142,\n    \"totalPages\": 8\n  }\n}\n```\n\n### Filtering\n\nUse query parameters for filters:\n\n```\nGET \u002Fapi\u002Ftasks?status=in_progress&assignee=user123&createdAfter=2025-01-01\n```\n\n### Partial Updates (PATCH)\n\nAccept partial objects — only update what's provided:\n\n```typescript\n\u002F\u002F Only title changes, everything else preserved\nPATCH \u002Fapi\u002Ftasks\u002F123\n{ \"title\": \"Updated title\" }\n```\n\n## TypeScript Interface Patterns\n\n### Use Discriminated Unions for Variants\n\n```typescript\n\u002F\u002F Good: Each variant is explicit\ntype TaskStatus =\n  | { type: 'pending' }\n  | { type: 'in_progress'; assignee: string; startedAt: Date }\n  | { type: 'completed'; completedAt: Date; completedBy: string }\n  | { type: 'cancelled'; reason: string; cancelledAt: Date };\n\n\u002F\u002F Consumer gets type narrowing\nfunction getStatusLabel(status: TaskStatus): string {\n  switch (status.type) {\n    case 'pending': return 'Pending';\n    case 'in_progress': return `In progress (${status.assignee})`;\n    case 'completed': return `Done on ${status.completedAt}`;\n    case 'cancelled': return `Cancelled: ${status.reason}`;\n  }\n}\n```\n\n### Input\u002FOutput Separation\n\n```typescript\n\u002F\u002F Input: what the caller provides\ninterface CreateTaskInput {\n  title: string;\n  description?: string;\n}\n\n\u002F\u002F Output: what the system returns (includes server-generated fields)\ninterface Task {\n  id: string;\n  title: string;\n  description: string | null;\n  createdAt: Date;\n  updatedAt: Date;\n  createdBy: string;\n}\n```\n\n### Use Branded Types for IDs\n\n```typescript\ntype TaskId = string & { readonly __brand: 'TaskId' };\ntype UserId = string & { readonly __brand: 'UserId' };\n\n\u002F\u002F Prevents accidentally passing a UserId where a TaskId is expected\nfunction getTask(id: TaskId): Promise\u003CTask> { ... }\n```\n\n## Common Rationalizations\n\n| Rationalization | Reality |\n|---|---|\n| \"We'll document the API later\" | The types ARE the documentation. Define them first. |\n| \"We don't need pagination for now\" | You will the moment someone has 100+ items. Add it from the start. |\n| \"PATCH is complicated, let's just use PUT\" | PUT requires the full object every time. PATCH is what clients actually want. |\n| \"We'll version the API when we need to\" | Breaking changes without versioning break consumers. Design for extension from the start. |\n| \"Nobody uses that undocumented behavior\" | Hyrum's Law: if it's observable, somebody depends on it. Treat every public behavior as a commitment. |\n| \"We can just maintain two versions\" | Multiple versions multiply maintenance cost and create diamond dependency problems. Prefer the One-Version Rule. |\n| \"Internal APIs don't need contracts\" | Internal consumers are still consumers. Contracts prevent coupling and enable parallel work. |\n\n## Red Flags\n\n- Endpoints that return different shapes depending on conditions\n- Inconsistent error formats across endpoints\n- Validation scattered throughout internal code instead of at boundaries\n- Breaking changes to existing fields (type changes, removals)\n- List endpoints without pagination\n- Verbs in REST URLs (`\u002Fapi\u002FcreateTask`, `\u002Fapi\u002FgetUsers`)\n- Third-party API responses used without validation or sanitization\n\n## Verification\n\nAfter designing an API:\n\n- [ ] Every endpoint has typed input and output schemas\n- [ ] Error responses follow a single consistent format\n- [ ] Validation happens at system boundaries only\n- [ ] List endpoints support pagination\n- [ ] New fields are additive and optional (backward compatible)\n- [ ] Naming follows consistent conventions across all endpoints\n- [ ] API documentation or types are committed alongside the implementation\n",{"name":5,"description":7},"master","2a22abcae4e5677b6e385b5a0e144c48baac4a94",".agentsmesh\u002Fpacks\u002Faddyosmani-agent-skills-pack\u002Fskills\u002Fapi-and-interface-design",7,"https:\u002F\u002Fgithub.com\u002FsampleXbro\u002Fagentsmesh","https:\u002F\u002Fsamplexbro.github.io\u002Fagentsmesh\u002F","https:\u002F\u002Fgithub.com\u002FsampleXbro","Senior Software Engineer · React · TypeScript · Next.js · Smart TV specialist (Tizen, webOS, Android TV)","2026-11-06 03:06:21",{"source":8,"skillName":5,"commands":74,"prompt":84,"zipAvailable":85},[75,78,81],{"tool":76,"command":77},"npx","npx skills add sampleXbro\u002Fagentsmesh --skill api-and-interface-design",{"tool":79,"command":80},"bunx","bunx skills add sampleXbro\u002Fagentsmesh --skill api-and-interface-design",{"tool":82,"command":83},"pnpm","pnpm dlx skills add sampleXbro\u002Fagentsmesh --skill api-and-interface-design","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FsampleXbro\u002Fagentsmesh\u002Fblob\u002Fmaster\u002F.agentsmesh\u002Fpacks\u002Faddyosmani-agent-skills-pack\u002Fskills\u002Fapi-and-interface-design\u002FSKILL.md",true,[],[88,102,118,135,141,160],{"skillNo":89,"name":90,"nameZh":6,"description":91,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":92,"categories":93,"keywords":97,"publishedAt":59},"01M6J2GJ4NDEPJND2GAXN0VPRB","research","Research docs and summarize decisions","https:\u002F\u002Fgithub.com\u002FsampleXbro\u002Fagentsmesh\u002Fblob\u002Fmaster\u002Ftests\u002Fe2e\u002Ffixtures\u002Fwindsurf-project\u002F.windsurf\u002Fskills\u002Fresearch\u002FSKILL.md",[94],{"categoryNo":95,"categoryName":96,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000021","资料检索与研究",[90,98,99,100,101],"docs","summarize","decisions","research docs",{"skillNo":103,"name":104,"nameZh":6,"description":105,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":106,"categories":107,"keywords":111,"publishedAt":59},"01M6J2GF8WQVFP75AMJWV7YM50","debugging","Systematic debugging workflow for production failures and test regressions.","https:\u002F\u002Fgithub.com\u002FsampleXbro\u002Fagentsmesh\u002Fblob\u002Fmaster\u002Ftests\u002Fe2e\u002Ffixtures\u002Fwarp-project\u002F.warp\u002Fskills\u002Fdebugging\u002FSKILL.md",[108],{"categoryNo":109,"categoryName":110,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[104,112,113,114,115,116,117],"systematic debugging","workflow","test","Production","systematic","for",{"skillNo":119,"name":120,"nameZh":6,"description":121,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":122,"categories":123,"keywords":127,"publishedAt":59},"01M6J2GAQRCM0KV565J63STPWB","api-generator","Generate REST API endpoints with validation and tests","https:\u002F\u002Fgithub.com\u002FsampleXbro\u002Fagentsmesh\u002Fblob\u002Fmaster\u002Ftests\u002Fe2e\u002Ffixtures\u002Ftrae-project\u002F.trae\u002Fskills\u002Fapi-generator\u002FSKILL.md",[124,125,126],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":109,"categoryName":110,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":30,"categoryName":31,"taxonomyType":32,"taxonomyTypeDesc":33},[45,128,129,57,51,130,131,132,133,134],"api generator","generator","rest api","tests","with","validation","generate",{"skillNo":136,"name":104,"nameZh":6,"description":105,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":137,"categories":138,"keywords":140,"publishedAt":59},"01M6J2G7VF3A2EGK5YBR4BM9KS","https:\u002F\u002Fgithub.com\u002FsampleXbro\u002Fagentsmesh\u002Fblob\u002Fmaster\u002Ftests\u002Fe2e\u002Ffixtures\u002Frovodev-project\u002F.rovodev\u002Fskills\u002Fdebugging\u002FSKILL.md",[139],{"categoryNo":109,"categoryName":110,"taxonomyType":21,"taxonomyTypeDesc":22},[104,117,113,114,112,115,116],{"skillNo":142,"name":143,"nameZh":6,"description":144,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":145,"categories":146,"keywords":148,"publishedAt":59},"01M6J2G4VHBHSPXGVQRZCH8CDW","typescript-pro","Apply advanced TypeScript patterns including conditional types, template literal types, and mapped types","https:\u002F\u002Fgithub.com\u002FsampleXbro\u002Fagentsmesh\u002Fblob\u002Fmaster\u002Ftests\u002Fe2e\u002Ffixtures\u002Froo-code-project\u002F.roo\u002Fskills\u002Ftypescript-pro\u002FSKILL.md",[147],{"categoryNo":30,"categoryName":31,"taxonomyType":32,"taxonomyTypeDesc":33},[149,150,151,152,153,154,155,156,157,158,159],"typescript","typescript pro","pro","patterns","code","architect","template","typescript patterns","Literal","types","advanced",{"skillNo":161,"name":104,"nameZh":6,"description":162,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":163,"categories":164,"keywords":166,"publishedAt":59},"01M6J2G2133FJ5SAHK9WX4YVNV","Systematic debugging workflow for Replit projects","https:\u002F\u002Fgithub.com\u002FsampleXbro\u002Fagentsmesh\u002Fblob\u002Fmaster\u002Ftests\u002Fe2e\u002Ffixtures\u002Freplit-agent-project\u002F.agents\u002Fskills\u002Fdebugging\u002FSKILL.md",[165],{"categoryNo":109,"categoryName":110,"taxonomyType":21,"taxonomyTypeDesc":22},[104,112,167,116,117,113],"projects"]