From omni
Generates interface contracts from logical entity capability boundaries, distinguishing external and internal interfaces with elements, change rules, and documentation. Explicitly invoked only by design skill.
npx claudepluginhub zte-aicloud/co-omnispec --plugin omniThis skill uses the workspace's default tool permissions.
- 仅被 `design` skill 显式调用
Defines API contracts, component interfaces, and data contracts before protocol/technology selection. For Large Track workflows with multi-component systems building APIs after TRD validation.
Writes API contracts in OpenAPI/AsyncAPI/GraphQL/gRPC/WebSocket/SSE/Webhook/SDK/file formats from PRD docs. Use after PRD approval, before HLD, to align teams on interfaces.
Guides designing API contracts in api-contract.md files with endpoint definitions, request/response schemas, TypeScript interfaces, and validation rules for backend-frontend coordination.
Share bugs, ideas, or general feedback.
design skill 显式调用注意事项:
ENTITY-XXXdesign / design-entity 一致)按以下顺序选用第一个存在的文件作为本次步骤的架构输入;均不存在则不阻塞,不将「缺少架构文件」视为失败,依赖 FEATURE_SPEC、context.md 与 IMPL_DESIGN 已有分层描述进行接口层次校验,并在必要时在契约说明中显式记录假设:
${DOC_DIR}/on-demand/logic_architecture.md(按需反构,优先)${DOC_DIR}/specs/logic_architecture.md(规格库)下文所称「有效架构约束文档」指按上式解析得到的文件;若未解析到任何文件,则称「未加载架构文档」。
FEATURE_SPEC 中的分层假设校验接口暴露层次与调用方向。FEATURE_DIR/context.md 中的「相关接口文档」章节,作为既有接口的主要参考来源。context_mode = evidence_first,优先消费 on_demand.scope.interfaces、on_demand.traceability、on_demand.contract_deltas、on_demand.risks、on_demand.evidence_gaps。基于步骤1输入与上下文,按「接口定义」识别并产出本次变更涉及的全部接口条目(含INSERT/MODIFY/DELETE/REFER),作为后续步骤的范围基线。
动作类型定义:
FEATURE_DIR/context.md 指向的既有接口文档进行修改。on-demand 接口消费规则(仅 evidence_first 模式):
on_demand.scope.interfaces 建立接口基线(白名单)。on_demand.contract_deltas 作为契约变化的主输入:
request_added[] → 请求参数新增/约束response_added[] / response_modified[] → 响应结构变化与兼容策略on_demand.traceability 校验每个接口是否有对应功能来源,避免“无来源接口”。on_demand.risks / on_demand.evidence_gaps 至少映射到一个错误处理或兼容说明条目。兼容规则(default 模式):
context_mode = default 或 on_demand 字段缺失,沿用原有逻辑,不阻塞接口设计。# 接口契约
## 对外接口
### [动作类型:INSERT/MODIFY/DELETE/REFER] - [接口ID] - [接口名称]
**变更原因**: [接口的变更描述]
**所属逻辑实体**: [逻辑实体ID] - [逻辑实体名称]
**调用方**: [谁调用/何时调用;INTERNAL需明确协作方]
[接口具体内容]
## 内部接口
### [接口名称]
**变更原因**: [接口的变更描述]
**调用方**: [谁调用/何时调用;INTERNAL需明确协作方]
[接口具体内容]
[按上述格式继续描述其他接口...]
业务意图 明确需要调整的契约要素(语义、参数/返回、约束、错误、流程)。对新增或修改的部分使用 **加粗** 标记,对计划移除的内容使用 ~~删除线~~ 标记,以便评审与追踪。DOC_DIR/specs/interfaces/0.interface_list.md,提取已存在的 API-XXX 最大ID,并以 最大ID + 1 作为新接口ID。0.interface_list.md 时,接口ID从 API-001 开始。.infra/metamodel/7.interface-template.md 中的规范生成[接口具体内容]:
DOC_DIR/specs/interfaces/ 下既有文档的组织方式与粒度,使新接口在抽象层级上与既有接口保持一致。从既有接口文档中提取对应条目的关键信息填入模板,变更原因 统一填写为 无变更,并补充可定位信息(文件路径/章节/锚点);无需重复粘贴契约全文。
FEATURE_DIR/contracts/api-contract.mdENTITY-XXX 的对外能力或内部协作诉求,避免“接口语义漂移”或职责重叠。API-XXX ID基于当前最大值顺序递增,无冲突或缺号。