changeset-validation

Validate changesets in openai-agents-js using LLM judgment against git diffs (including uncommitted local changes). Use when packages/ or .changeset/ are modified, or when verifying PR changeset compliance and bump level.

Install
npx skills add 'https://github.com/openai/openai-agents-js/tree/main/.agents/skills/changeset-validation'
Download bundle ↓
main · 506f736Scanned 2026-09-17

Contributors

GitHub-linked commit authors for this SKILL.md at the saved revision. Co-authors and history before file renames are not included.

File history ↗
View on GitHub
← Back to SKILL.md

Use $changeset-validation skill. Use $changeset-validation. It should be located at .agents/skills/changeset-validation under the root directory of this repository.

You are validating changesets for the openai-agents-js monorepo.

Return JSON only. The output must be a JSON object with:

  • ok: boolean
  • errors: string[] (polite, actionable English sentences)
  • warnings: string[] (polite, actionable English sentences)
  • required_bump: "patch" | "minor" | "major" | "none"

Always use English in errors and warnings, regardless of the conversation language.

Rules to enforce:

  1. Allowed package names are fixed and must be used exactly as listed.
  2. Use the changed packages list + diff to judge whether changeset packages are correct and reflect the actual changes.
  3. If any package under packages/ changed, at least one changeset must exist and must include every changed package. Only count changeset files listed in CHANGESET_FILES (i.e., added/modified in the current branch diff).
  4. If CHANGESET_FILES lists one or more changeset files for the current branch, do not require creating additional new changeset files for incremental branch changes; instead require updating the existing changeset(s) so they cover all changed packages and reflect the latest diff.
  5. If no packages changed, changesets are optional; if present, they still must be consistent with the diff.
  6. Each changeset summary must be 1-2 non-empty lines.
  7. If the PR body contains GitHub issue references like #123 and a changeset exists, the changeset summary should include those references.
  8. required_bump is the minimum semver bump required by the diff. Default bump is patch. Judge breaking changes against the latest release tag, not against unreleased branch-only churn or post-tag changes already on main. Rewriting or removing APIs introduced after the latest release tag is not by itself a breaking change. Require minor only when there is a breaking change, dropped support, or a behaviorally significant feature that changes existing workflows or expectations (not simply additive APIs or types). Do not require minor solely because new APIs, options, or types were added; additive features can stay patch when they do not change existing behavior. If you are unsure between patch and minor, prefer patch. Major is allowed only after the first major release and only for changes that warrant a major release (breaking changes, dropped support, or significant behavior shifts). Before the first major release, do not use major bumps for feature-level changes. Exception: if the new feature is explicitly labeled experimental/preview in the diff (e.g., module name, docs, comments, or exports) and does not change existing behavior, a patch bump is acceptable.
  9. If an existing changeset uses a bump larger than required_bump, treat that as an error by default and ask to lower it to the minimum required bump.
  10. Exception: if PR labels include changeset:minor-approved, an intentional minor bump is allowed for an otherwise patch-level change. In that case, do not ask to lower a minor changeset to patch, but still keep required_bump set to the minimum required bump.
  11. If changeset:minor-approved is present and a changeset exists, the summary should make the feature scope clear rather than using a vague summary.
  12. required_bump must be "none" when there are no package changes.
  13. If unknown package directories are changed, treat it as an error.

If changeset entries include packages that do not appear changed, add a warning (unless the diff indicates a valid reason). If the changeset summary is too vague or clearly unrelated to the diff, add an error. When a changeset file exists in CHANGESET_FILES but is missing packages or no longer reflects the diff, the error should instruct updating the existing changeset file(s), not creating a new one. Do not treat changeset files outside CHANGESET_FILES as satisfying the requirement.

Context: Allowed packages: {{ALLOWED_PACKAGES}}

Unknown package directories: {{UNKNOWN_PACKAGE_DIRS}}

Changed packages: {{CHANGED_PACKAGES}}

Changed files: {{CHANGED_FILES}}

Changeset files:

{{CHANGESET_FILES}}

Notes:

  • Only the content inside each fenced md block under "Changeset files" is the actual changeset file content.
  • The changeset file list includes only files present in the head commit; deleted or renamed source paths may be omitted.

PR body (CI only; otherwise this may be "(not provided)"): {{PR_BODY}}

PR labels (CI only; otherwise this may be "(not provided)"): {{PR_LABELS}}

Package diff (truncated if large): {{PACKAGE_DIFF}}

Referenced from SKILL.md