otel-changelog-pr-verifier
OTel Changelog PR Verifier
Verify CHANGELOG.md entries in an OpenTelemetry Go repository against the referenced GitHub pull requests.
Operating Mode
Prioritize:
- exact PR-to-entry matching before prose quality
- the release section under review, not the entire changelog
- concrete mismatches only
- local repository evidence first, GitHub metadata second
Do not flood the user with entries that are already correct.
Execution Assumption
Assume the user has provided a concrete target PR, usually as a PR number or PR URL in the current repository.
The default example repository is open-telemetry/opentelemetry-go, but the same workflow applies to similar OpenTelemetry Go repositories when the task is already anchored to a specific repository and PR.
Workflow
1. Check out the target PR locally
Prefer:
gh pr checkout <pr-number>
git status --short --branch
gh pr view <pr-number> --json baseRefName
If the local checkout is not already anchored to the target repository, use an explicit repo selector:
gh pr checkout <pr-number> -R <owner/repo>
git remote -v
gh pr view <pr-number> -R <owner/repo> --json baseRefName
If gh cannot reach GitHub because of sandbox restrictions, request escalation and retry.
Detect the PR base branch from GitHub metadata and use origin/<base-branch> for diffs instead of assuming main.
For concrete command patterns and output templates, see references/workflow.md.
2. Isolate the release section under review
Read only the relevant CHANGELOG.md block, usually the newest released section above the previous release.
Prefer commands such as:
git diff origin/<base-branch>...HEAD -- CHANGELOG.md
nl -ba CHANGELOG.md | sed -n '<start>,<end>p'
awk '/^## \[<release>\]/{flag=1;print;next}/^## \[<previous-release>\]/{flag=0}flag' CHANGELOG.md
If the user only cares about entries introduced by the release PR, review only that released section.
3. Extract the referenced PR numbers
Collect unique #NNNN values from the target section.
Prefer:
awk '/^## \[<release>\]/{flag=1;next}/^## \[<previous-release>\]/{flag=0}flag' CHANGELOG.md | rg -o '#[0-9]+' -N | sort -u
4. Fetch PR metadata from GitHub
Use gh pr view for each referenced number.
Prefer:
gh pr view <number> --json number,title,url,state,mergedAt
If the current repository context is not already clear, make the repository explicit:
gh pr view <number> -R <owner/repo> --json number,title,url,state,mergedAt
If needed, batch with a shell loop. Request escalation if network access is blocked.
5. Compare changelog text to PR metadata
For each entry, verify:
- the PR number resolves to the expected GitHub PR
- the PR title and changed area are consistent with the changelog description
- the entry is not obviously pointing at the wrong PR
Treat these as mismatches:
- changelog description refers to a different feature or package than the PR
- PR number resolves to a different topic than the entry text
- entry claims a fix/addition that is not plausibly what the PR did
Do not flag harmless wording differences if the referenced PR is clearly the same change.
When deciding whether wording is "close enough", use the matching heuristics in references/workflow.md.
6. Report only the incorrect items
Default output:
No incorrect entries found.
If mismatches exist, return a compact list:
- CHANGELOG line <line>: `<entry text>` uses `#<number>`, but PR title is `<title>`.
Correct PR: <if known>
PR URL: <url>
Review Rules
- Prefer the actual release section over guessing from the diff summary.
- Use exact line references when reporting problems.
- If all entries are consistent, say so directly.
- Keep the answer focused on incorrect references; a full mapping table is optional and only on request.
More from flc1125/skills
subagent-orchestrator
Orchestrate subagent workflows for complex tasks that benefit from decomposition, role-based delegation, and parallel execution. Use when Codex should assemble a temporary team of subagents, choose roles from a reusable role library, create a controlled fallback role when no preset role fits, coordinate read-heavy work in parallel, or handle write-heavy work with ownership boundaries, staged execution, and an integrator-led merge path.
31yuque
Work with Yuque OpenAPI for reading, searching, creating, and updating users, groups, repos, docs, TOC structures, versions, and statistics. Use when Codex needs to operate on Yuque knowledge bases or documents, reorganize document placement in a repo, inspect API capabilities, or prepare guarded plans for destructive Yuque actions.
30experts
Assemble a panel of experts to assess a problem from multiple professional perspectives, surface agreement and disagreement, and deliver a chaired recommendation with clear tradeoffs. Use when the user wants multi-expert judgment, a second opinion, design critique, option comparison, or a recommendation backed by distinct expert viewpoints.
24study
Guide structured learning for a topic by diagnosing current level, defining stage goals, building a learning path, generating practice, and running review loops. Use when the user wants to learn something step by step, start from zero, build a study plan, prepare for an exam or skill, get guided practice, or continue a topic through staged coaching rather than a one-off answer.
13github-create-pr
Create GitHub pull requests from a local branch using a reviewable workflow for branch checks, diff analysis, PR title/body writing, and gh CLI creation. Use when opening a PR, drafting or improving a PR description, preparing a branch for review, or adding reviewers on GitHub.
13async
Launch and coordinate Codex subagents as deferred tasks. Use when the user wants to start bounded subagent work now, keep the main thread moving without waiting by default, then later join, collect, or redirect that work through a stable task reference.
12