nemoclaw-maintainer-release-notes

Files (1)

• SKILL.md

SKILL.md (first lines)

<!-- SPDX-FileCopyrightText: Copyright (c) 2026 NVIDIA CORPORATION & AFFILIATES. All rights reserved. -->
<!-- SPDX-License-Identifier: Apache-2.0 -->

# NemoClaw Maintainer Release Notes

Draft NemoClaw release notes from live release data. The house style is:

- three narrative lead paragraphs,
- a categorized list of shipped changes,
- one "what changed and why it matters / why we did it" bullet for every included shipped change,
- external-only contributor thanks,
- visible `#NNNN` GitHub links.

Create a local Markdown draft. Do not create or update a GitHub Discussion; the maintainer posts the announcement manually.

## Prerequisites

- You must be in the NemoClaw git repository.
- `gh` must be authenticated for `NVIDIA/NemoClaw`.
- The release tag should already exist. If the user is still cutting the tag, use `nemoclaw-maintainer-cut-release-tag` first.
- Use live GitHub and remote tag state, not memory or a stale local branch.
- If `<release-dir>/notes-data.json` exists from `npm run release:notes-data`, use it as the starting source of truth and query GitHub only to fill missing fields.
- If `notes-data.json` has `status: "partial"` or non-empty `pullRequestWarnings`, report those warnings and ask the maintainer whether to fetch or fill the missing PR metadata before drafting.

## Step 1: Verify the Release Range

Identify the current release tag and previous release tag. If the user gives only the current version, derive the previous semver tag from remote tags.

```bash
git ls-remote https://github.com/YYC-Cube/YYC3-NemoClaw.git \
  refs/heads/main \
  refs/tags/<previous-version> 'refs/tags/<previous-version>^{}' \
  refs/tags/<current-version> 'refs/tags/<current-version>^{}' \
  refs/tags/latest 'refs/tags/latest^{}'
```

Confirm:

- `<current-version>^{}` peels to the intended release commit.
- `latest` points to the same peeled commit unless the user explicitly says otherwise.
- The compare range is `<previous-version>...<current-version>`.

## Step 2: Collect the Shipped Surface

If `notes-data.json` exists, read it first. Otherwise, use the compare API as the first source of truth:

```bash
gh api repos/NVIDIA/NemoClaw/compare/<previous-version>...<current-version> \
  --jq '{status,ahead_by,total_commits,commits:[.commits[] | {sha:.sha, headline:(.commit.message|split("\n")[0]), author:.commit.author.name}], files:[.files[] | {filename,status,changes}]}'
```

For each PR number in commit headlines, collect live PR metadata:

```bash
gh pr view <number> --repo NVIDIA/NemoClaw \
  --json number,title,author,headRepositoryOwner,url,mergeCommit,labels,body,mergedAt
```

Also inspect any shipped commit that does not have a PR number in the headline. Include it only if it is a real shipped change worth announcing.

## Step 3: Decide What to Include

Include the shipped product, docs, release-surface, and CI confidence changes that a reader should know about.

For each included item, write:

- what changed,
- why it matters or why we did it,
- a visible PR link like `[#4474](https://github.com/YYC-Cube/YYC3-NemoClaw/pull/4474)`.

Be careful with sensitive internal cleanup:

- Do not count testing reverts or guardrail reversions as release value unless the user explicitly asks for a full raw changelog.
- If a revert-like commit must be mentioned, use neutral language and do not frame it as someone else's mistake.
- Avoid public wording that could embarrass a teammate.

## Step 4: Categorize the Changes

Use categories that match the release surface. Prefer 4-6 sections. Common categories:

- OpenClaw, Sandbox, and Network Stability
- Windows, WSL, and Onboarding Recovery
- Messaging and OpenClaw Runtime Activation
- Hermes and Inference
- Skills, Docs, and Release Surface
- CI and Release Confidence

Every included shipped change should appear in exactly one category unless the user asks for a shorter note.

## Step 5: Handle Contributor Credit

By default, thank external contributors only. Do not thank NVIDIA/internal contributors by GitHub ID unless the user explicitly asks.

Determine external contributors from live GitHub state:

```bash
for login in <github-logins>; do
  code=$(gh api -i orgs/NVIDIA/members/$login 2>/dev/null \
    | sed -n '1s/.* \([0-9][0-9][0-9]\).*/\1/p' || true)
  printf '%s %s\n' "$login" "${code:-unknown}"
done
```

Interpretation:

- `204` means the account is a visible member of `NVIDIA`.
- `404` means the account is not a visible member and should be treated as external for release-note thanks.

Replay PRs need special care:

- If a maintainer replayed an external PR, inspect the replay PR body and the original PR.
- Credit the original external GitHub username in the issue-level bullet for the shipped replay.
- Also thank that username in the final thanks section.
- Do not mention affiliations, organizations, domains, or companies unless the user explicitly asks. Use the GitHub username only.

Example:

```markdown
- [#4474](https://github.com/YYC-Cube/YYC3-NemoClaw/pull/4474) replays and narrows the Hermes Provider host-smoke fix originally contributed by @shannonsands in [#4385](https://github.com/YYC-Cube/YYC3-NemoClaw/pull/4385). ...

From YYC-Cube/YYC3-NemoClaw, Apache-2.0.

More from YYC-Cube/YYC3-NemoClaw