Add a Gutenberg release knowledge skill - #80627
Conversation
MaggieCabrera
added
the
[Type] Developer Documentation
There was a problem hiding this comment.
Pull request overview
Adds a new repository-local Agent Skill (gutenberg-release-knowledge) that guides a release-learning workflow: identify PRs shipped in a specific Gutenberg release, extract durable guidance from discussions, verify against current mainline, and draft a small documentation/instructions PR.
Changes:
- Introduces a new Skill definition (
SKILL.md) describing the end-to-end release evidence collection, weighing, verification, and draft-PR workflow. - Adds a reference document (
references/people.md) for trust-tier weighting, including how to fetch the livegutenberg-coreteam list plus a dated snapshot fallback. - Adds an agent interface configuration (
agents/openai.yaml) to expose the skill with a display name and default prompt.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| .agents/skills/gutenberg-release-knowledge/SKILL.md | Defines the skill’s scope, evidence selection/verification rules, and draft-PR preparation steps. |
| .agents/skills/gutenberg-release-knowledge/references/people.md | Provides trust-tier guidance and a maintainer snapshot for weighing discussion evidence. |
| .agents/skills/gutenberg-release-knowledge/agents/openai.yaml | Registers the skill UI metadata and a default prompt for invoking it. |
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
|
For reference, here are ten PRs produced by running this skill separately against individual stable Gutenberg releases:
Some intervening stable releases produced no PR because the analysis did not find a durable documentation or contributor-guidance gap. RCs were not considered. These PRs are ready for review and intentionally open to disagreement or closure. Their review discussions should help show where the skill is useful, where it is too eager or too conservative, and what should be refined before it is integrated into the release process. |
|
|
||
| ## Tier 2: maintainers | ||
|
|
||
| Snapshot as of 2026-07-22. This includes the two leaders above. |
There was a problem hiding this comment.
Do we need this list if we have a way to fetch it.
There was a problem hiding this comment.
Yeah, I'm not very comfortable hardcoding this list. We're not doing a good job at keeping such lists up to date.
There was a problem hiding this comment.
Updated this to not use that list anymore
|
|
||
| ## Tier 2: maintainers | ||
|
|
||
| Snapshot as of 2026-07-22. This includes the two leaders above. |
There was a problem hiding this comment.
Yeah, I'm not very comfortable hardcoding this list. We're not doing a good job at keeping such lists up to date.
|
|
||
| 1. Query the target repository's current labels. Select the smallest set of existing labels that describes the proposed change, using labels from the source PRs as evidence when they still fit. Never create a label just for the generated PR. | ||
| 2. Tag with `@handle` the people whose substantive discussion, review, or authored rationale directly informed the proposal alongside the corresponding evidence links in the PR body. | ||
| 3. Request reviews only from those named evidence participants. Exclude bots, reaction-only participants, passive requested reviewers, broad props lists, and people whose comments did not inform the proposal. Use the trust weighting above to keep the list focused when several people support the same point. |
There was a problem hiding this comment.
Doesn't this still risk extra noise? We might want to avoid review requests, but to rather just suggest who to ping while testing this in practice.
There was a problem hiding this comment.
mmh, do you mean now that I am manually triggering for multiple releases or when this eventually becomes part of the release process? It shouldn't generate too many PRs for release and I think a ping is relevant if a change you made to the codebase should have been documented. Now I wonder if this should be integrated on PR update and run manually for each one...
| @@ -0,0 +1,138 @@ | |||
| --- | |||
| name: gutenberg-release-knowledge | |||
There was a problem hiding this comment.
Not 100% sure this skill doesn't belong in https://github.com/WordPress/agent-skills. Having these more centrally, especially since some of the release work is related to WordPress core and backporting etc. - all good reasons to have WP core release maintenance and release skills living in the same place.
There was a problem hiding this comment.
I'm happy to discuss it, but as is agent-skills is mainly used for skills that the community uses. The release knowledge skill is something only Gutenberg maintainers will do.
@WordPress/agent-skills-maintainers what do you think?
| ## Inputs and scope | ||
|
|
||
| - Require an explicit Gutenberg release number such as `23.6`. | ||
| - Reject release candidates and other prereleases; accept only a published stable release. |
There was a problem hiding this comment.
Would it be useful for a release lead to run this before publishing a RC?
There was a problem hiding this comment.
We could, but I don't know that there's a value on having it run both at the RC and the stable releases, so I just chose the stable out of the two.
bgrgicak
left a comment
bgrgicak
left a comment
There was a problem hiding this comment.
I ran it on 23.5 and it added Stabilizing a private API instructions which sounds reasonable.
|
I added a general framework for us to follow when adding skills. Could you rebase trunk then ask an agent to follow the new structure to apply this skill? |
891e5d0 to
28bfb40
Compare
What?
Adds a repository-local skill that analyzes the discussions and implementation shipped in a named Gutenberg release, then prepares focused draft documentation or instruction updates.
Why?
The goal of the skill is to extract some insights from every release that informs our docs both for humans and machines. If the test run is succesful we next step is to automate the skill to run on every release cycle.
This PR gives us a repeatable way to run a few release-learning pilots, discuss the resulting PRs, and refine the workflow before considering integration with the release script.
Discussion
This is an experimental workflow, not a settled solution. Please challenge the scope, evidence rules, generated PR format, or any other assumption. Closing this PR is also a useful outcome if this is not the right direction. Discussion here and on the generated pilot PRs will be used to fine-tune the skill before any release-script integration.