release-intel-mcp / reproducible workflow
Build release notes from evidence between two Git refs
A release summary is more trustworthy when every claim can be traced back to a commit, pull request, issue, or contributor in a precisely bounded range.
short answer
What this workflow gives you
Use this workflow when a changelog, deployment note, or stakeholder update must match a specific release range. The evidence record keeps direct commits visible, preserves repository links, and separates collection from the later editorial step.
Bound the range
Choose an older and newer tag, branch, or commit. The comparison never silently expands beyond those refs.
git rev-parse v1.4.0 v1.5.0Collect evidence
Read the compare result and associate commits with merged pull requests, labels, linked issues, and authors.
release-intel-report owner/repository v1.4.0 v1.5.0Expose gaps
Keep direct commits visible and surface warnings when GitHub truncates a large comparison or a lookup fails.
release-intel-report owner/repository v1.4.0 v1.5.0 --json | jq '.warnings, .all_commits'Write last
Use the structured record as the input for release notes, then review the narrative against the linked repository evidence.
release-intel-report owner/repository v1.4.0 v1.5.0 > release-evidence.mdobserved result
Fourteen commits become a bounded release evidence record.
The stable range v0.5.1 to commit 8a2f350 was inspected with the published server against its own public GitHub history.
interpretation
Keep the evidence chain intact
Write the prose only after the range, statistics, warnings, merged pull requests, and direct commits are visible in one record. Every sentence in the final notes should map back to that bounded evidence.
operating limits
What this workflow does not prove
- Requires GitHub read access for the repositories being inspected
- Output quality depends on repository labels, issue links, and pull request hygiene
- The server returns release context; a client still decides the final narrative