Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/openai/openai-agents-python/release-candidate-prepnpx skills add openai/openai-agents-python --skill release-candidate-prepgit clone --depth 1 https://github.com/openai/openai-agents-pythonWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00087 | $0.03771 |
| Opus 5 | $0.00044 | $0.01886 |
| Sonnet 5 | $0.00017 | $0.00754 |
| Haiku 4.5 | $0.00009 | $0.00377 |
Grade A, and why
release-candidate-prep scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 179 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Release Candidate Preparation
Use this skill only when the user explicitly invokes $release-candidate-prep and supplies a release version without a leading v, for example VERSION=0.20.1. This skill replaces the removed GitHub Actions release-PR creator with a reviewed local workflow.
Non-negotiable boundaries
- Treat explicit invocation as authorization to fetch
origin/main, create one dedicated detached release worktree, run branch-free release-readiness gates there, create or replace the localrelease/v<version>in that worktree only after those gates pass, update the three release-owned files, and create one local commit. If the branch already exists locally or remotely, the required final local state is still exact currentorigin/mainplus only the new release commit; an existing local branch may be replaced only when it is not checked out in another worktree. - Keep the user's source checkout on its existing clean
maincommit. Do not fast-forward it, switch its branch, or materialize release files there. Leave the dedicated release worktree in place for green handoff, blocked review, or recoverable failure. - Never push, open or edit a pull request, add labels or milestones, create a release, or otherwise mutate GitHub. Never run
gh. - Own exactly
pyproject.toml,uv.lock, andtests/fixtures/released_api_contract.json. Runtime, documentation, workflow, or other repository changes must land onmainbefore release preparation. - Do not stash, delete, overwrite or remove an existing worktree, or work around unrelated local changes. Fail before branch creation when the initial checkout is dirty or is not on
main, the dedicated worktree is not clean and detached at refreshedorigin/main, an existing local release branch is checked out in another worktree, the prospective packaged-contract gate fails after the allowed dependency-bootstrap recovery, the planning review blocks, ororigin/mainadvances after those gates run. - Treat
$final-release-reviewas the controlling release checker, not only as a report generator. Its planning gate must be green before branch creation, and its final-candidate gate must inspect the materialized worktree and be green before PR-ready handoff. Any candidate content, commit, or base change invalidates the previous green result. - Remove inherited
OPENAI_API_KEYfrom every child command. Release preparation does not require a live OpenAI API request. - Stop after the local commit, final release review, and copy-ready handoff. The user owns the push and pull-request creation.
What ships with it
2 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2d ago First seen · 179 lines · 87 tokens per session scan A 2d506f9785f7
release-candidate-prep is a skill published in the GitHub repository openai/openai-agents-python (29,075 stars, last pushed 4d ago), licensed MIT. It adds 87 tokens to every session and 3,771 once invoked, about $0.0004 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
thinking-out-loud
A contract for what the agent does when a long, messy, stream-of-consciousness ramble arrives (usually voice dictation): act on nothing until the echo brief is approved. The echo audits the entire transfer, mission, locked decisions and constraints, open questions, flips and parked tangents, with the model's…
stripe-projects
Use after E2B sandbox/API access has been provisioned through Stripe Projects and the user needs to use the resulting E2B API key with the E2B CLI, JavaScript SDK, Python SDK, or Code Interpreter SDK.
code-review
Code review assistance with linting, style checking, and best practices.
haiku
When writing a haiku for this bot, follow these conventions.
cli-e2e
Write, modify, or debug Docker-based Composio CLI end-to-end tests under ts/e2e-tests/cli, including binary invocation, fixture isolation, output assertions, and package manifests. Use for CLI E2E test suites only; use cli-command for CLI source implementation.
python-release
Handle Python SDK release, build, bump, packaging metadata, PyPI client pin, uv.lock, nox/build workflow, and publish verification changes. Use for Python release process work or dependency pin bumps; do not use for ordinary Python feature implementation.