NO-ISSUE: docs(skills): guard release notes against a truncated git log

[hhk7734]

Summary

Cutting v0.5.0 nearly dropped PRs #98–#107 from the release notes: a git log --oneline --no-merges listing rendered only 50 of the range's 59 commits, with no warning. This hardens the release skill against that.

The first commit blamed git log for a 50-commit cap and prescribed an explicit -n. Both halves were wrong, and the second commit corrects them:

• Redirected to a file, git log --oneline --no-merges, the same command with -n 500, and git rev-list all return an identical 60 commits. git log is not capped.
• The 50-line cut comes from the layer rendering the output — the same one that clips long subject lines mid-word — and reproduces or not depending on the surrounding command, never on a git flag.
• So -n was never the cure: it does not change what git emits, and a hard-coded -n 200 only relocates the silent truncation to 200 commits.

What the skill now says instead:

• Treat git rev-list --no-merges --count as the oracle and cross-check the listing length against it.
• On a mismatch, redirect to a file and read the file — the one form that reliably survives.
• Read each PR number from its own commit rather than from a possibly-clipped subject line, with the SHA list itself going through a file.

Test Plan

• git log is not capped: to a file, --oneline --no-merges, -n 500, and git rev-list all yield 60 commits for v0.4.0..HEAD, and the two listings are byte-identical (diff clean).
• Truncation reproduced as a rendering artifact: the same pipeline returns 50 in one command shape and 60 in another, with no git flag changing between them.
• Documented commands recover the full set on v0.4.0..52f1fbf: oracle count 59, file listing 59, 59 PR rows, unique PRs spanning MAF-19394: feat(preset): add vLLM v0.15.1 E2E presets for H100/H200 GPUs #98–MAF-20668: docs(skills): correct the KV cache events guidance in guide-odin #174.
• No hard-coded -n limit remains in the skill (grep -n '\-n 200' → no matches).
• Complies with the root AGENTS.md: docs(skills) matches the documented type and scope, and all added comments are in English.

🤖 Generated with Claude Code

[Copilot]

Pull request overview

This PR updates the release skill documentation to make release-note generation resilient to environments where git log output is silently capped (e.g., at 50 commits), which can otherwise cause missing commits/PRs in release notes.

Changes:

• Added a git rev-list --no-merges --count cross-check before listing commits.
• Added explicit -n 200 limits to git log invocations to avoid the silent 50-commit cap.
• Added a per-commit loop to extract PR numbers from each commit subject rather than relying on a possibly clipped one-line listing.

Suppressed comments (1)

.agents/skills/release/SKILL.md:137

• Step 3a says to verify the list length matches the commit count, but the commands still hard-code -n 200. If there are >200 commits between releases, this can truncate and break the cross-check (and the per-commit PR extraction loop). Consider deriving -n from the git rev-list --count value and reusing it for all subsequent logs in this step.

# Commits between releases. Verify the list length matches this count -- see step 1.
git rev-list --no-merges --count <prevVersion>..<releaseVersion>
git log <prevVersion>..<releaseVersion> --oneline --no-merges -n 200

# Long subjects can get clipped in tool output, hiding the trailing PR number.
# Pull the PR number per commit instead of trusting a wrapped subject line.
for c in $(git log <prevVersion>..<releaseVersion> --no-merges -n 200 --format='%h'); do
    echo "$c $(git log -1 "$c" --format='%s' | grep -oE '#[0-9]+' | head -1)"

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

Suppressed comments (2)

.agents/skills/release/SKILL.md:95

• The PR description says the skill now adds an explicit -n 200 to both git log calls, but this guide now explicitly recommends not using -n (and the commands shown do not include it). Please align the PR description with the actual guidance so reviewers/users don’t get conflicting instructions about how to avoid truncation.

# List commits since last stable tag, then check the list is as long as the count
# above. `git log` itself is not capped, but the terminal or agent tool rendering
# its output may truncate it, which silently drops commits from the release notes.
git log <latest-stable-tag>..HEAD --oneline --no-merges

If the listing is shorter than the count, do not work around it with -n -- the
limit is in the rendering, not in git log. Redirect to a file and read the file,
which is the only form that reliably survives:

**.agents/skills/release/SKILL.md:143**
* Step 3a says to “fall back to the file form from step 1” if the rendered `git log` output is truncated, but step 1’s file snippet is for `<latest-stable-tag>..HEAD` and doesn’t show the equivalent file-based commands for `<prevVersion>..<releaseVersion>`. Adding the explicit file-based commands here would make the instructions unambiguous and copy/paste safe.

Commits between releases. Cross-check the list length against this count, and

fall back to the file form from step 1 if the two disagree.

git rev-list --no-merges --count ..
git log .. --oneline --no-merges

</details>