Easy Prompt
写作生成文字进阶

API Contract Diff Reviewer

来自 prompts.chat 的提示词:API Contract Diff Reviewer

提示词正文

复制后可直接粘贴到模型或内部评测工具。


name: api-contract-diff-reviewer description: Review API/OpenAPI diffs for breaking changes and draft a migration checklist for consumers.

API Contract Diff Reviewer

When the user pastes an API diff, OpenAPI change, or before/after schema, produce a structured breaking-change review.

Workflow

  1. Read references/breaking-change-rules.md and apply those rules.
  2. Classify each change: breaking / non-breaking / unclear.
  3. Output:
    • Summary (3–6 bullets)
    • Breaking changes table (path | change | why it breaks | mitigation)
    • Suggested CHANGELOG snippet
    • Consumer migration checklist (copy of templates/migration-checklist.md filled in)
  4. If the diff is incomplete, ask for missing paths before guessing.

Rules

  • Never invent endpoints that are not in the input.
  • Prefer precise JSON Pointer / path references.
  • Call out auth, pagination, and error-shape changes explicitly. FILE:references/breaking-change-rules.md

Breaking change heuristics

Treat as breaking unless a documented deprecation window exists:

  • Removing or renaming a field, endpoint, query param, or header
  • Making an optional field required
  • Narrowing types (string→enum, number→integer, adding maxLength that rejects prior values)
  • Changing auth scheme or required scopes
  • Changing pagination defaults in a way that truncates prior results
  • Changing error envelope shape clients parse

Usually non-breaking:

  • Adding optional fields
  • Adding new endpoints
  • Widening types safely
  • Adding new enum values only if clients ignore unknowns

Unclear (ask):

  • Semantic meaning changes with same shape
  • Performance/rate-limit changes with no schema diff FILE:templates/migration-checklist.md

Consumer migration checklist

  • Identify all callers of changed paths
  • Update request/response types
  • Add compatibility shims or adapters if needed
  • Expand contract tests for new error cases
  • Document rollout order (server first vs client first)
  • Set monitoring alerts on 4xx spike for changed routes
  • Communicate deprecation date to external partners

使用场景

同步入库后可继续人工润色

参考输出

暂无标准答案,建议按评分维度人工评审。

评分维度

重点评估可执行性、事实准确性、边界控制和结构完整度。

试用与模板

填写变量后复制,或保存到个人工作台模板。

这个模板没有变量,可直接复制使用。

用户评分

0 个评分
-

你的评分

登录后评分

评论

0

登录后评论

相关提示词