implementation-strategy

Choose compatibility-aware implementation approaches for runtime and API changes in openai-agents-python.

Updated May 23, 2026
One-click install
npx skills add https://github.com/kiranimmadi2/promptforge-ai --skill implementation-strategy-kiranimmadi2
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: implementation-strategy
Source: https://github.com/kiranimmadi2/promptforge-ai/tree/main/openai-agents-python/.agents/skills/implementation-strategy
Command: npx skills add https://github.com/kiranimmadi2/promptforge-ai --skill implementation-strategy-kiranimmadi2

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? When changing runtime behavior, exported APIs, serialized state, or configuration surfaces in the openai-agents-python SDK, it is easy to either break released contracts or over-engineer shims for unreleased code. This Skill provides a decision framework for judging breaking-change risk against the latest release tag before editing code. ## Core Features & Use Cases - Compatibility boundary analysis: Classify changes as released public API, unreleased branch-local interfaces, internal helpers, or durable external state, and decide whether shims, migrations, or direct rewrites are warranted. - Release-tag grounding: Resolve the latest release tag from the origin remote (falling back to local tags) so breaking-change judgments are based on shipped contracts, not branch churn. - SDK-specific rules: Guidance for OpenAI API feature gaps, streaming vs non-streaming parity, public dataclass field ordering, strict-mode opt-ins, and None semantics for configuration. - Use Case: Before refactoring a session persistence API on a feature branch, use this Skill to confirm the interface is unreleased, then rewrite it directly without adding aliases or deprecation shims. ## Quick Start Use the implementation-strategy skill to decide the compatibility boundary and implementation approach before I edit this runtime code.

Frequently Asked Questions about implementation-strategy

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I decide if an API change is a breaking change?

Compare the change against the latest release tag, not against unreleased branch churn. If the interface shipped in that tag or defines a supported durable external state boundary, treat it as breaking; otherwise rewrite it directly.

When should I add a compatibility shim or migration path?

Add a compatibility layer only when there is a concrete released consumer, a supported durable external state boundary such as persisted schema or serialized state, or an explicit user request for migration support. Unreleased interfaces should be rewritten directly.

How do I find the latest release tag for compatibility checks?

Resolve the tag from the origin remote first using the find_latest_release_tag.sh script, and fall back to local git tags sorted by version only when remote tags are unavailable. Treat local-tag results as potentially stale.

Should unreleased interfaces on main be preserved with aliases?

No. Interfaces added after the latest release tag are not semver breaking changes, so prefer deletion or replacement over aliases, overloads, shims, or feature flags. Update callers, tests, and docs directly.

How should new fields be added to public dataclasses?

Append new optional fields or constructor parameters at the end of public dataclasses and constructors. Do not insert them before existing fields unless you also provide a compatibility layer and regression coverage for the old positional call shape.