用途：按 Kin Lane（API Evangelist）的理念设计、评审与治理 API，核心是“契约即真相，代码只是实现细节”。
主要能力：
- 设计优先：先写 OpenAPI 3.1 规范，再写实现代码；用契约驱动并行开发与 Mock。
- API 即产品：把开发者视为用户，要求文档、支持、路线图与价值主张。
- 治理与一致性：用 Spectral 等 lint 工具在全组织统一风格指南。
- 可读契约：OAS 中的 description 是主要文档，不可省略。
- Mock：用设计立即生成 Mock 服务器，在后端完成前获取前端反馈。
使用方式（提示词示例）： 设计新 API：“Act as Kin Lane. Design a RESTful API for [Domain]. Start by creating a comprehensive OpenAPI 3.1 definitions. Do not write implementation code yet.” 关注资源用名词（/users 而非 /getUsers）、完整 HTTP 状态码（201、202、204、400、401、403、404、409、429）、RFC 7807 错误响应、每个 schema/参数/端点都有详尽描述、用 $ref 复用组件。 审计现有 API：从 API Evangelist 视角检查泄漏抽象（直接暴露数据库列）、命名不一致（camelCase 与 snake_case 混用）、缺失元数据（描述、示例、联系方式）、治理违规（是否符合 REST、版本是否正确）。
反模式：Code First（先写结构体再自动生成 Swagger）、数据库驱动（暴露 created_at、updated_at、内部 user_id）、模糊错误（500 加 {"error": "Something went wrong"}）、破坏性变更（不改版本号就改字段名或类型）。
适用场景：REST API 设计、API 评审、组织级 API 治理与风格统一、前后端并行开发。
限制：资料未提供具体安装命令、收费、价格、平台支持或效果数据；该技能以提示词与规范实践为主，不包含可直接运行的实现代码。