Skip to content

Reframe prepare-providers-documentation skill as an optional aid #68641

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
potiuk merged 1 commit into from
Jun 17, 2026
Merged

Reframe prepare-providers-documentation skill as an optional aid #68641

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
20 changes: 19 additions & 1 deletion dev/README_RELEASE_PROVIDERS.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -196,14 +196,32 @@ First thing that release manager has to do is to convert commits for each provid
and update version of the provider to a target version - depending on type of changes implemented in the
providers.

The recommended way to do this is via the **`prepare-providers-documentation` skill** loaded by an
One option for doing this is the **`prepare-providers-documentation` skill** loaded by an
agentic coding framework (e.g. Claude Code or OpenAI Codex CLI), which replaces the manual
commit-by-commit classification step of `breeze release-management
prepare-provider-documentation` with AI-driven classification. The skill inspects every PR (using
sub-agents per PR for thorough analysis), pays special attention to potentially breaking changes by
reading the actual diff (not just the commit message or PR labels), scopes multi-provider PRs to the
slice that touched the current provider, and asks the release manager only when genuinely uncertain.

> [!WARNING]
> The skill is an **optional** aid, not a required or default part of the release process. The
> interactive `breeze release-management prepare-provider-documentation` command (see
> [Falling back to interactive breeze](#falling-back-to-interactive-breeze)) remains the baseline,
> and release managers who do not use AI tooling should use that command directly — this skill is
> not for them. If you do use the skill, keep the following in mind:
>
> * **You must verify its output.** The version bumps and changelog entries it produces are
> generated by an LLM and are **not authoritative** — the release manager is responsible for
> reviewing every generated entry (especially breaking-change classification and version bumps)
> before merging the release PR. Treat the skill's output as a first draft to be checked, not a
> final answer.
> * **It runs for a long time and consumes a lot of tokens.** Classifying a full release wave with
> per-PR sub-agents can take a while and burn through a large amount of model tokens. Because of
> that, it is hard to recommend without a high-capacity plan (e.g. Claude Max, or an equivalent
> GitHub Copilot / OpenAI tier). On a metered or low-quota plan the cost may be significant and
> the run may not complete.

**Prerequisites:** running this skill requires an agentic coding environment with the
[GitHub MCP server](https://github.com/github/github-mcp-server) configured — the skill reads PR
diffs, lists commits, and (with maintainer confirmation) edits files via these tools. Two well-known
Expand Down