Final Release Review

Final Release Review is an official skill from OpenAI’s openai-agents-python repository. Its direct primary source is the .agents/skills/final-release-review directory. The skill supports reviewing a Python SDK release candidate or a planned release against the previous published version. Its purpose is not merely to produce a polished report, but to reach an accountable decision about whether a candidate can ship or must be blocked. According to the provider, the workflow should find concrete regressions and release risks, independently determine the compatible release type, review open documentation changes, and produce an actionable release handoff.

Purpose and operating method

The workflow starts by locating the latest release tag and resolving the target commit, normally from the main branch. It then distinguishes pre-release planning from final-candidate review. In planning mode, the next release type may still be unspecified, so the skill recommends the smallest compatible type from the actual diff. For a final candidate, intent, package metadata, lockfile, and release branch are compared more strictly. This separation prevents unchanged version metadata from being treated as a blocker during early planning, while still blocking a genuinely under-versioned final release.

The review compares the base and target rather than inspecting the target in isolation. Public Python interfaces are examined for exports, identity, signatures, positional order, defaults, enumerations, and documented behavior. Package review also covers supported Python versions, dependencies, extras, distribution contents, and import behavior. Changes to durable state, protocols, configuration, or environment variables must be checked for backward reads and for a usable migration or compatibility path. According to the provider, a risk should become a blocker only when the diff proves an introduced regression, a confirmed breaking change without a usable fallback, an unresolved data or security problem, or a broken release-critical path.

Documentation and outcome

A major strength of the skill is its separate treatment of documentation readiness. The technical review first derives the actual documentation obligations. Current open documentation pull requests are then searched through read-only access before any obligation is called uncovered. Several changes can collectively cover one obligation, while an open pull request is still not part of the release target. The report therefore distinguishes covered, partially covered, not covered, stale or conflicting, and unverified states. Missing documentation alone does not block a release, but it should produce a concrete post-release handoff naming the relevant file, section, example, or migration wording.

The final report keeps the controlling release call distinct from explanatory prose. A green light to ship means the review found no proven blocker under the applicable versioning policy. A blocked result must state the evidence, impact, affected files, action, and exit condition. In planning mode, the recommendation can be a release type rather than a final ship decision. This makes the result useful both for maintainers preparing a release and for teams evaluating a candidate that already has release metadata.

Use, limits, and safety

Final Release Review is a review playbook, not an automatic merge bot and not a replacement for maintainers, security owners, or final product approval. It does not authorize changes to pull requests. A green result is valid only while the reviewed target and relevant candidate contents remain unchanged. Any later change to the diff, metadata, lockfile, or contract requires a complete new review. The instructions also explain that source code, comments, and local project information may be sent to the connected model provider. Do not place credentials, tokens, private diffs, or confidential test content in prompts, examples, or stored results. Inspecting a repository locally does not automatically mean connected model calls remain local.

The skill is well suited to maintainers and development teams that need a traceable, repeatable release decision. It does not replace CI or product acceptance and does not prove complete security. The practical result depends on the selected base tag, target commit, branch, package state, and available GitHub information. The official Agents Python documentation at openai.github.io/openai-agents-python/ provides useful surrounding context for the SDK. The repository identifies Apache-2.0 as its license according to the provider. This description was checked on September 9, 2026 against the official skill file and official OpenAI Agents documentation. GitHub stars are intentionally not stored because the Skill model has no supported field for them.