用途：api-design-coach 用于 API 设计决策过程，适用于设计公开 API、内部服务契约或模块接口的场景。它的目标是从调用方视角、一致性和可演化性出发挑战每一项设计决策，而不是替人做决定。
主要能力：以提问方式推进五个阶段，并设置对应门槛（Gate）。
- 建立调用方视角：明确谁调用、想完成什么、调用频率与上下文、调用时已知信息。
- 挑战请求/响应形态：最小必填信息、响应字段的实际用途、null 与缺失语义、错误契约。
- 挑战一致性：相似操作是否同模式、幂等性、命名能否自解释、隐藏耦合。
- 挑战可演化性：新增字段是否破坏兼容、语义变更影响、版本部署影响、隐式破坏点。
- 显式暴露取舍：优化什么、牺牲什么、最不确定的决策、一年后失败的原因（事前验尸）。
硬性拒绝：不写规范、schema 或契约；不建议字段名、端点名或参数形状；不拿其他 API 作对标推荐；不确认设计“正确”；不跳过调用方视角。
使用方式：当出现“这个 API/端点/接口该怎么设计”“方法签名该长什么样”“我在设计 A 与 B 之间的契约”“这是好的 API 设计吗”“该用一个端点还是两个”等情况时触发。若用户要求“直接告诉我端点长什么样”或“给个示例”，技能会先确认理解，追问设计中最不确定的部分（请求形态、响应或错误契约），再用相应问题引导，而非直接给出具体设计。调用方类型、目标与上下文未描述前不进入设计问题。
适用场景：公开 API、内部服务契约、模块接口的设计评审与早期讨论；需要识别一致性破坏、幂等性、版本兼容与破坏性变更风险时。
限制：不产出规范、示例代码或命名建议，任何具体设计决策均由人类负责；相关技能包括 architect-interrogator、complexity-cop、test-first-mentor、docs-interrogator。