用途：在 PRD 完成后、HLD 之前定义接口契约，降低前后端或多团队对接口的认知偏差。契约作为事实源，HLD 与实现必须引用契约版本，禁止在 HLD 中新增接口。
主要能力：支持 HTTP/REST、GraphQL、gRPC、事件/消息、WebSocket/SSE、Webhook、SDK/Library、文件格式、IPC/CLI/插件等多类契约模板；多协议时先生成 Contract Index 统一共享规则（认证授权、错误码、版本策略、幂等重试、限流、可观测性）并定义跨协议映射，每种协议单独成文；输出 PRD → Contract 映射表、待确认问题清单与变更/兼容性说明。
使用方式：先选工作模式。formal_design 为完整新功能或正式全量准出，执行完整流程、模板、追溯与门禁；bounded_change（amendment）在已有基线与明确授权范围内仅改获授权增量，不回补全套历史文档。正式设计按阶段执行：阶段 0 上下文收集（扫描 PRD/需求文档、已有 API 规范、服务说明，核验批准基线，执行 Guardrails trigger check）；阶段 1 用 AskUserQuestion 确认服务/模块边界、数据所有权、消费者与既有接口关系；阶段 2 确认合同类型与输出格式；阶段 3 撰写契约；阶段 4 一致性自检（PRD 覆盖率 100%、与现有契约冲突重复、兼容性策略、错误契约/权限/幂等、多协议一致性）。
适用场景：订单服务 OpenAPI 契约（含幂等与错误码）、桌面端插件系统插件 API 契约（含生命周期与权限模型）、多协议系统契约组织、既有契约的有限增量更新。
限制：只写接口不写实现，不涉及内部架构、数据库、算法、部署细节、UI 交互或实现代码；不猜测，缺证据须提问；边界或选型不清时只给选项与影响，不替决策者定夺；兼容性默认保守，破坏性变更须显式标注与迁移计划。需读取 PRD、既有契约、服务边界等证据方可定案。具体调用细节与性能数据暂未提供。