⚠️

重要前提

安装AI Skills的关键前提是：必须科学上网，且开启TUN模式，这一点至关重要，直接决定安装能否顺利完成，在此郑重提醒三遍：科学上网，科学上网，科学上网。查看完整安装教程 →

OpenAI Agents Python 最终发布评审指南：自动化发布流程与风险管理

final-release-review by openai/openai-agents-python

85 周安装量

20,700 GitHub Stars

GitHub

安装命令

npx skills add https://github.com/openai/openai-agents-python --skill final-release-review

软件工程自动化开发运维

🇨🇳中文介绍

最终发布评审

目的

在验证最新发布候选提交（默认为 origin/main 的顶端）以进行发布时使用此技能。它指导您获取远程标签、选择上一个发布标签，并彻底检查 BASE_TAG...TARGET 差异，以发现破坏性变更、引入的错误/回归、改进机会和发布风险。

评审必须是稳定且可操作的：通过使用明确的准入规则避免不同运行之间的差异，并且在没有具体证据和清晰的解除阻塞操作时，绝不产生 BLOCKED 调用。

快速开始

确保在仓库根目录：pwd → path-to-workspace/openai-agents-python。
同步标签并选择基准标签（默认为 v*）：

BASE_TAG="$(.agents/skills/final-release-review/scripts/find_latest_release_tag.sh origin 'v*')"
选择目标提交（默认为 origin/main 的顶端，确保是最新的）：然后。

广告位招租

在这里展示您的产品或服务

触达数万 AI 开发者，精准高效

联系我们

确定性准入策略

默认情况下为 🟢 绿灯放行，除非满足以下至少一个阻塞触发条件。
仅当您能引用具体的发布阻塞证据并提供可操作的解除阻塞步骤时，才使用 🔴 阻塞。
阻塞触发条件（BLOCKED 至少需要满足一条）：
- 在 BASE...TARGET 中确认引入了回归或错误（例如，目标测试失败、差异中存在不兼容行为，或移除了行为但没有回退方案）。
- 确认存在破坏性的公共 API/协议/配置变更，且缺少版本控制或版本控制不匹配，并且没有迁移路径（例如，针对破坏性变更的补丁发布）。
- 存在具体的数据丢失、损坏或影响安全的变更，且未解决缓解措施。
- 发布关键的分发/构建/运行时路径被差异破坏（非推测性）。
本身不构成阻塞：
- 差异大小、大规模重构或涉及许多文件。
- 没有具体证据的“可能回归”风险陈述。
- 未在本地运行测试。
如果证据不完整，则发出 🟢 绿灯放行，并附带有针对性的验证后续步骤，而不是 BLOCKED。

准备
- 运行快速开始中的标签命令，确保使用最新的远程标签。如果标签模式不同，请覆盖模式参数（例如 '*.*.*'）。
- 如果用户指定了基准标签，优先使用它，但仍需先获取远程标签。
- 保持工作树清洁，以避免差异噪音。
假设
- 假设目标提交（默认为 origin/main 的顶端）已经在 CI 中通过了 $code-change-verification，除非用户另有说明。
- 不要仅仅因为您没有在本地运行测试而阻止发布；专注于具体的行为或 API 风险。
- 发布策略：常规发布使用补丁版本；仅在进行破坏性变更或添加主要功能时使用次要版本。主版本号保留到 1.0 发布。
映射差异
- 使用 --stat、--dirstat 和 --name-status 输出，以发现热点目录和文件类型。
- 对于可疑文件，优先使用 git diff --word-diff BASE...TARGET -- <path>。
- 注意任何被删除或新添加的测试、配置、迁移或脚本。
分析风险
- 遍历 references/review-checklist.md 中的类别（破坏性变更、回归线索、改进机会）。
- 当您怀疑存在风险时，请引用具体的文件/提交并解释行为影响。
- 对于每个发现，必须包含以下所有内容：证据、影响 和 操作。
- 严重性校准：
  - 🟢 低：影响范围小或行为已明确覆盖；不影响发布准入。
  - 🟡 中等：可能存在面向用户的回归信号；需要验证但不是已确认的阻塞项。
  - 🔴 高：已确认或有强有力证据的发布阻塞问题。
- 在时间紧张时，建议使用最小化、高信号价值的验证命令（有针对性的测试或检查器），而不是通用的重新运行。
- 破坏性变更如果已经通过适当的版本升级和迁移/升级说明进行了覆盖，并不自动要求 BLOCKED 发布调用；仅当版本升级缺失/不匹配（例如，补丁升级）或破坏性变更引入了未解决的风险时才应阻止。
形成建议
- 明确说明 BASE_TAG 和 TARGET。
- 提供简洁的差异摘要（关键目录/文件和数量）。
- 列出：潜在的破坏性变更、可能的回归/错误、改进机会、缺失的发布说明/迁移。
- 建议批准/阻止，并在阻塞时提供确切的解除阻塞检查项。如果破坏性变更已正确进行版本控制（次要/主要），您仍可以建议绿灯放行，同时指出该变更。在发布调用中使用表情符号和粗体，使准入状态显而易见。
- 如果您无法提供具体的解除阻塞检查项，请不要使用 BLOCKED。

输出格式（必需）

所有输出必须使用英文。

在每次使用此技能生成的响应中，使用以下报告结构。积极主动并果断：在顶部附近做出明确的批准/阻止调用，并为每个发现分配明确的风险级别（低/中等/高）并附带简短的影响陈述。当风险较低且测试通过时，避免过度谨慎的措辞。

在 Diff 部分始终使用固定的仓库 URL (https://github.com/openai/openai-agents-python/compare/...)。不要使用 ${GITHUB_REPOSITORY} 或任何其他模板变量。将风险级别格式化为粗体表情符号标签：🟢 LOW、🟡 MODERATE、🔴 HIGH。

每个风险发现都必须包含一个可操作的后续步骤。如果报告使用了 **🔴 BLOCKED**，请包含一个 解除阻塞检查清单 部分，其中至少包含一个具体的命令/任务和一个通过条件。

### 发布就绪评审 (<tag> -> TARGET <ref>)

这是由 `$final-release-review` 技能完成的发布就绪报告。

### 差异

https://github.com/openai/openai-agents-python/compare/<tag>...<target-commit>

### 发布调用：
**<🟢 GREEN LIGHT TO SHIP | 🔴 BLOCKED>** <一行理由>

### 范围摘要：
- <N 个文件变更 (+A/-D)；涉及的关键区域：...>

### 风险评估（按影响排序）：
1) **<发现标题>**
   - 风险：**<🟢 LOW | 🟡 MODERATE | 🔴 HIGH>**。<一句话影响陈述。>
   - 证据：<具体的差异/测试/提交信号；避免笼统陈述>
   - 文件：<路径>
   - 操作：<具有通过标准的具体后续步骤命令/任务>
2) ...

### 解除阻塞检查清单（当发布调用为 BLOCKED 时必需）：
1. [ ] <具体的检查/修复>
   - 退出标准：<必须满足什么条件才能解除阻塞>
2. ...

### 备注：
- <工作树状态、标签/目标假设或重新运行指导>

如果未发现风险，请在风险评估下包含一行“未发现重大风险”，并仍然提供批准调用。如果您未在本地运行验证，请不要添加验证状态部分或将其用作发布阻塞项；在备注中简要说明任何假设。如果报告未被阻塞，请省略 解除阻塞检查清单 部分。

scripts/find_latest_release_tag.sh：获取远程标签并返回与模式匹配的最新标签（默认为 v*）。
references/review-checklist.md：用于发现破坏性变更、回归和发布完善差距的详细信号和命令。

🇺🇸English

Final Release Review

Purpose

Use this skill when validating the latest release candidate commit (default tip of origin/main) for release. It guides you to fetch remote tags, pick the previous release tag, and thoroughly inspect the BASE_TAG...TARGET diff for breaking changes, introduced bugs/regressions, improvement opportunities, and release risks.

The review must be stable and actionable: avoid variance between runs by using explicit gate rules, and never produce a BLOCKED call without concrete evidence and clear unblock actions.

Quick start

Ensure repository root: pwd → path-to-workspace/openai-agents-python.
Sync tags and pick base (default v*):

BASE_TAG="$(.agents/skills/final-release-review/scripts/find_latest_release_tag.sh origin 'v*')"
Choose target commit (default tip of origin/main, ensure fresh): git fetch origin main --prune then TARGET="$(git rev-parse origin/main)".
Snapshot scope:

git diff --stat "${BASE_TAG}"..."${TARGET}" git diff --dirstat=files,0 "${BASE_TAG}"..."${TARGET}" git log --oneline --reverse "${BASE_TAG}".."${TARGET}" git diff --name-status "${BASE_TAG}"..."${TARGET}"
Deep review using references/review-checklist.md to spot breaking changes, regressions, and improvement chances.
Capture findings and call the release gate: ship/block with conditions; propose focused tests for risky areas.

Deterministic gate policy

Default to 🟢 GREEN LIGHT TO SHIP unless at least one blocking trigger below is satisfied.
Use 🔴 BLOCKED only when you can cite concrete release-blocking evidence and provide actionable unblock steps.
Blocking triggers (at least one required for BLOCKED):
- A confirmed regression or bug introduced in BASE...TARGET (for example, failing targeted test, incompatible behavior in diff, or removed behavior without fallback).
- A confirmed breaking public API/protocol/config change with missing or mismatched versioning and no migration path (for example, patch release for a breaking change).
- A concrete data-loss, corruption, or security-impacting change with unresolved mitigation.
- A release-critical packaging/build/runtime path is broken by the diff (not speculative).
Non-blocking by itself:
- Large diff size, broad refactor, or many touched files.
- "Could regress" risk statements without concrete evidence.
- Not running tests locally.
If evidence is incomplete, issue 🟢 GREEN LIGHT TO SHIP with targeted validation follow-ups instead of BLOCKED.

Workflow

Prepare
- Run the quick-start tag command to ensure you use the latest remote tag. If the tag pattern differs, override the pattern argument (e.g., '*.*.*').
- If the user specifies a base tag, prefer it but still fetch remote tags first.
- Keep the working tree clean to avoid diff noise.
Assumptions
- Assume the target commit (default origin/main tip) has already passed $code-change-verification in CI unless the user says otherwise.
- Do not block a release solely because you did not run tests locally; focus on concrete behavioral or API risks.
- Release policy: routine releases use patch versions; use minor only for breaking changes or major feature additions. Major versions are reserved until the 1.0 release.
Map the diff
- Use --stat, --dirstat, and --name-status outputs to spot hot directories and file types.

Output format (required)

All output must be in English.

Use the following report structure in every response produced by this skill. Be proactive and decisive: make a clear ship/block call near the top, and assign an explicit risk level (LOW/MODERATE/HIGH) to each finding with a short impact statement. Avoid overly cautious hedging when the risk is low and tests passed.

Always use the fixed repository URL in the Diff section (https://github.com/openai/openai-agents-python/compare/...). Do not use ${GITHUB_REPOSITORY} or any other template variable. Format risk levels as bold emoji labels: 🟢 LOW , 🟡 MODERATE , 🔴 HIGH.

Every risk finding must contain an actionable next step. If the report uses **🔴 BLOCKED**, include an Unblock checklist section with at least one concrete command/task and a pass condition.

### Release readiness review (<tag> -> TARGET <ref>)

This is a release readiness report done by `$final-release-review` skill.

### Diff

https://github.com/openai/openai-agents-python/compare/<tag>...<target-commit>

### Release call:
**<🟢 GREEN LIGHT TO SHIP | 🔴 BLOCKED>** <one-line rationale>

### Scope summary:
- <N files changed (+A/-D); key areas touched: ...>

### Risk assessment (ordered by impact):
1) **<Finding title>**
   - Risk: **<🟢 LOW | 🟡 MODERATE | 🔴 HIGH>**. <Impact statement in one sentence.>
   - Evidence: <specific diff/test/commit signal; avoid generic statements>
   - Files: <path(s)>
   - Action: <concrete next step command/task with pass criteria>
2) ...

### Unblock checklist (required when Release call is BLOCKED):
1. [ ] <concrete check/fix>
   - Exit criteria: <what must be true to unblock>
2. ...

### Notes:
- <working tree status, tag/target assumptions, or re-run guidance>

If no risks are found, include a “No material risks identified” line under Risk assessment and still provide a ship call. If you did not run local verification, do not add a verification status section or use it as a release blocker; note any assumptions briefly in Notes. If the report is not blocked, omit the Unblock checklist section.

Resources

scripts/find_latest_release_tag.sh: Fetches remote tags and returns the newest tag matching a pattern (default v*).
references/review-checklist.md: Detailed signals and commands for spotting breaking changes, regressions, and release polish gaps.

Weekly Installs

Repository

openai/openai-a…s-python

GitHub Stars

20.4K

First Seen

Jan 24, 2026

Security Audits

Gen Agent Trust HubPass SocketPass SnykPass

Installed on

opencode71

github-copilot70

codex68

gemini-cli68

cursor67

claude-code65

Azure Data Explorer (Kusto) 查询技能：KQL数据分析、日志遥测与时间序列处理

152,400 周安装

For suspicious files, prefer git diff --word-diff BASE...TARGET -- <path>.

Note any deleted or newly added tests, config, migrations, or scripts.

Analyze risk

Walk through the categories in references/review-checklist.md (breaking changes, regression clues, improvement opportunities).
When you suspect a risk, cite the specific file/commit and explain the behavioral impact.
For every finding, include all of: Evidence, Impact, and Action.
Severity calibration:
- 🟢 LOW : low blast radius or clearly covered behavior; no release gate impact.
- 🟡 MODERATE : plausible user-facing regression signal; needs validation but not a confirmed blocker.
- 🔴 HIGH : confirmed or strongly evidenced release-blocking issue.
Suggest minimal, high-signal validation commands (targeted tests or linters) instead of generic reruns when time is tight.
Breaking changes do not automatically require a BLOCKED release call when they are already covered by an appropriate version bump and migration/upgrade notes; only block when the bump is missing/mismatched (e.g., patch bump) or when the breaking change introduces unresolved risk.

Form a recommendation

State BASE_TAG and TARGET explicitly.
Provide a concise diff summary (key directories/files and counts).
List: breaking-change candidates, probable regressions/bugs, improvement opportunities, missing release notes/migrations.
Recommend ship/block and the exact checks needed to unblock if blocking. If a breaking change is properly versioned (minor/major), you may still recommend a GREEN LIGHT TO SHIP while calling out the change. Use emoji and boldface in the release call to make the gate obvious.
If you cannot provide a concrete unblock checklist item, do not use BLOCKED.