用途：编写 API 规范，即 API 表面的工程线协议，描述每个操作在传输层的样子：请求与响应形状（字段、类型、必填/可选、约束）、认证模型、错误模型与可用示例。目标是契约可实现、可调用——客户端工程师能正确调用每个操作，服务端工程师无需询问作者即可实现。
主要能力：从已批准的功能规范出发，把每个行为映射为一个或多个操作；按项目所用 API 风格（REST 用 OpenAPI/JSON-Schema，GraphQL 用 SDL，RPC/gRPC 用 proto）渲染契约；要求请求与响应两侧完全类型化，每个字段标注必填/可选与约束，每个响应绑定状态码；定义共享数据类型并引用而非重复；说明认证方案与每个非公开操作所需 scope/角色；给出统一错误形状（如 REST 的 RFC 9457 Problem Details）并逐操作枚举失败情形与可重试性；为集合操作定义分页、过滤、排序与速率限制；每个主要操作至少一个与模式一致的请求/响应示例。
使用方式：先由 api-spec 模板工具提供章节结构，本技能提供填充方法；读取上游功能规范、架构文档与数据模型，用深度研究能力将契约建立在既有 API 设计实践上；按章节方法填写；对已批准契约的变更走增量修订流程，区分附加式与破坏性变更，破坏性变更走新版本与弃用→日落生命周期；交付前按无歧义标准自检。
适用场景：从已批准功能规范编写 API 规范；为 REST、GraphQL 或 RPC/gRPC 表面指定操作、模式、认证、错误与示例；填充 api-spec 模板；以版本化增量修订已批准规范。
限制：不用于设计持久化数据模型、编写面向消费者的 API 参考文档、编写实现/架构、评审或评分已完成的 api-spec（应使用 reviewing-api-spec）、编写功能规范本身。若缺少研究能力，不得编造字段名、限制、状态码或错误码，应标记为待验证假设；上游信息不足时应作为阻塞项或开放问题提出，而非虚构形状。具体模板工具与深度研究能力是否可用、收费与平台信息暂未提供。