feat(publish): create draft GitHub release with AI-generated notes

[james-elicx]

Summary

• Adds a Create GitHub Release step to the publish workflow, placed after the tag push and AI summary generation
• Release is created as a draft so it can be reviewed and published manually
• Uses the AI-generated bullet points as the release body (falls back to a commit log URL if AI is unavailable)
• Uses ${{ github.token }} with the existing contents: write permission — no new secrets required

[james-elicx]

/bigbonk review please

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/vinext@360

commit: 6027130

[github-actions]

Example	Preview	Production	Original
app-router-cloudflare	preview	production
pages-router-cloudflare	preview	production
app-router-playground	preview	production	original
realworld-api-rest	preview	production
nextra-docs-template	preview	production
benchmarks	preview	production
hackernews	preview	production	original

[ask-bonk]

The change is small and well-scoped. Here's my review:

---

The PR looks good. It adds a gh release create step (lines 144-154) that slots in naturally between the AI summary generation and the Google Chat notification. A few observations:

What's correct:

• Uses ${{ github.token }} which already has contents: write — no new secrets needed.
• --draft is the right call; lets maintainers review the AI-generated notes before publishing.
• Placement is correct: after the tag push (line 81) and summary generation (line 142), before the notification (line 156).
• The SUMMARY variable already has a fallback to the commit log URL (line 131), so the release body is always populated.

One minor concern — shell quoting of SUMMARY:

On line 152, --notes "${SUMMARY}" passes the multi-line AI summary through shell expansion. If the summary contains characters like ", $, or backticks, they'll be interpreted by the shell. The Google Chat step (line 164) avoids this by piping through jq -n with --arg, which handles escaping properly.

A safer approach would be:

run: |
  gh release create "v${VERSION}" \
    --title "v${VERSION}" \
    --notes-file - \
    --draft \
    --repo "${{ github.repository }}" <<< "${SUMMARY}"

Or pass it via a temp file / --notes-file /tmp/summary.txt. This avoids any shell metacharacter issues in the AI-generated text.

That said, this is a low-probability edge case (the AI prompt asks for bullet points, unlikely to produce shell metacharacters), and the release is a draft anyway so any garbled output would be caught before publishing. I'd call it a nice-to-have hardening, not a blocker.

Verdict: Ship it. Optionally harden the --notes quoting if you want to be defensive.

github run

[james-elicx]

/bigbonk re-review please

[ask-bonk]

Here's the re-review. The previous feedback still applies, and the change is in good shape overall. Updated assessment:

---

Still looks good. The diff has two logical pieces:

1. Improved commit log format and AI prompt (lines 86, 88, 91, 111-117) — switches from --oneline to %h %s (%aN) to include author names, bumps max_tokens from 300 to 1024, bumps the fallback commit count from 20 to 30, and rewrites the prompt to produce proper GitHub release notes with headings and contributor credits. All sensible changes.

2. New Create GitHub Release step (lines 145-155) — creates a draft release using gh release create. Placement is correct (after tag push + summary, before notification). Uses ${{ github.token }} with existing contents: write permission.

The shell quoting concern from the first review still stands (line 153). The --notes "${SUMMARY}" approach is vulnerable to shell metacharacters in the AI-generated text. The summary is now longer and richer (full markdown with headings, bullets, contributor names), which increases the surface area for characters like backticks in code references or $ in cost/pricing mentions.

The --notes-file - approach from the first review is the cleanest fix:

run: |
  gh release create "v${VERSION}" \
    --title "v${VERSION}" \
    --notes-file - \
    --draft \
    --repo "${{ github.repository }}" <<< "${SUMMARY}"

One new observation: The step has no continue-on-error: true or if: success() guard. If gh release create fails (e.g., the tag doesn't exist on the remote yet due to a race, or GitHub API hiccup), it will fail the entire workflow — meaning the Google Chat notification step won't run even though the npm publish already succeeded. Consider adding continue-on-error: true to match the pattern used by the notification step (line 159), since the release is a draft and can always be created manually.

Verdict: Same as before — ship it. The quoting hardening and continue-on-error are nice-to-haves, not blockers.

github run

[james-elicx]

/bigbonk re-review please

[ask-bonk]

All feedback from previous reviews addressed. Shell quoting uses --notes-file - with here-string, continue-on-error: true is set, and the rest of the changes (richer commit format, expanded prompt, higher token limit) are sensible. LGTM.

[ask-bonk]

PR approved. Both issues from the earlier reviews (shell quoting and continue-on-error) are resolved in the latest push. No remaining concerns.

github run