agentleFS
NVIDIAKnown publisherNVIDIA/Model-Optimizer/skills/modelopt-release-cherry-pick/SKILL.md

modelopt-release-cherry-pick

Skill5.6k starsChanged 3 days agoApache-2.0View on GitHub

Audit merged bug-fix PRs and release NVBugs for missing cherry-pick labels, then cherry-pick labeled PRs into a release branch and open a PR. Use when asked to "cherry-pick PRs for release/X.Y.Z", "pick PRs to release branch", "verify cherry-pick labels", or "cherry-pick labeled PRs".

  • Commits and pushes

Trending

More talk lately.about the whole repository

Dec 2025: 0 mentionsJan 2026: 2 mentionsFeb 2026: 1 mentionMar 2026: 0 mentionsApr 2026: 2 mentionsMay 2026: 1 mentionJun 2026: 0 mentionsJul 2026: 0 mentionsAug 2026: 2 mentionsSep 2026: 20 mentionsOct 2026: 15 mentionsNov 2026: 11 mentions
Dec 2025Jun 2026Nov 2026
Mentions a month of the NVIDIA/Model-Optimizer repository that our weekly crawl found. There is no adoption data for this file yet.

Who's talking about NVIDIA/Model-Optimizer

The biggest 5 of 54 mentions linking to the repository that our crawl found. Each line is their own headline.

See all 54

Talked about on GitHub and Bluesky (54 times).

On GitHub · 50

45 more on GitHub

The file

We split this skill into the rules it gives an agent

10 rules. About 0 are common, 5 are distinctive, and 5 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈5

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 5

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Ask the user for the release version (e.g.

    line 12
  2. Distinctive:

    Before fetching the labeled queue, audit for missing bug fixes:

    line 18
  3. Very specific:

    Use the NVBugs MCP to search for every NVBug whose Keywords field contains the exact keyword Committed_ModelOpt_<VERSION>.

    line 25
  4. Distinctive:

    Use these recommendation values and sort the table in this order:

    line 90
  5. Very specific:

    Use — when no NVBug is known.

    line 96
  6. Distinctive:

    Do not label unmerged PRs, PRs not based on main, or candidates classified Unclear without explicit approval.

    line 104
  7. Distinctive:

    Use the GitHub search API to list PRs that have the cherry-pick label but not cherry-pick-done, sorted by merge date ascending:

    line 108
  8. Very specific:

    Check out release/<VERSION>, creating it from the remote if it doesn't exist locally:

    line 120
  9. Distinctive:

    All PRs are squash-merged, so each has a single-parent commit.

    line 129
  10. Very specific:

    Add the cherry-pick-done label to every PR that was successfully cherry-picked:

    line 173

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Cherry-pick PRs to a Release Branch

Cherry-pick all merged main PRs labeled cherry-pick-<version> (but not cherry-pick-done) into the corresponding release/<version> branch, one by one in merge order.

Step 1 — Identify the target version

Ask the user for the release version (e.g. 0.44.0) and target release candidate (e.g. rc2) if not already provided. Confirm whether this is the final RC.

Set VERSION=<version> for use in subsequent steps.

Step 2 — Audit candidates for missing labels

Before fetching the labeled queue, audit for missing bug fixes:

  • Non-final RC: audit release NVBugs and recent merged PRs.
  • Final RC: audit only fixes tied to NVBugs with the exact keyword Committed_ModelOpt_<VERSION> and QA-verification evidence for the fix. Verify that evidence in the NVBug or linked QA results before recommending Needs label; if missing or unclear, classify as Unknown and ask for confirmation. Skip the general recent-PR audit; do not introduce general bug-fix PRs or fixes tied only to NVBugs committed for another release.

Audit release NVBugs

Use the NVBugs MCP to search for every NVBug whose Keywords field contains the exact keyword Committed_ModelOpt_<VERSION>. Follow pagination until no next token is returned.

Fetch each matching NVBug with its comments. Extract every Model-Optimizer PR link or unambiguous PR #<NUM> reference from the comments, not only the latest comment. Keep only PRs that are merged into main, lack cherry-pick-<VERSION>, and are not already included in the release branch. Verify each remaining PR is a bug fix. The NVBug keyword is evidence for review, not by itself proof that every linked PR should be picked.

Audit recent merged PRs

For non-final RCs only: Audit PRs merged into main since the latest release candidate. Exclude PRs that already have cherry-pick-<VERSION> and changes already present on the release branch:

git fetch origin main "release/$VERSION" --tags
RC_TAG=$(git tag --merged "origin/release/$VERSION" \
  --list "${VERSION}rc*" --sort=-version:refname | head -1)
test -n "$RC_TAG" || {
  echo "No ${VERSION}rc* tag found on origin/release/$VERSION" >&2
  exit 1
}
SINCE=$(git for-each-ref --format='%(creatordate:iso-strict)' \
  "refs/tags/$RC_TAG")

PATCH_STATUS=$(git cherry "origin/release/$VERSION" origin/main)

SEARCH_RESULTS=$(
  gh search prs \
    --repo NVIDIA/Model-Optimizer \
    --merged \
    --base main \
    --merged-at ">=$SINCE" \
    --limit 1000 \
    --json number,title,author,labels,url \
    -- "-label:cherry-pick-$VERSION"
)

if test "$(jq 'length' <<<"$SEARCH_RESULTS")" -ge 1000; then
  echo "Recent-PR audit reached the 1,000-result limit" >&2
  exit 1
fi

jq -r '.[].number' <<<"$SEARCH_RESULTS" \
  | while read -r pr; do
      sha=$(gh pr view "$pr" --repo NVIDIA/Model-Optimizer \
        --json mergeCommit --jq '.mergeCommit.oid')
      if grep -q "^+ $sha$" <<<"$PATCH_STATUS"; then
        gh pr view "$pr" --repo NVIDIA/Model-Optimizer \
          --json number,title,author,labels,url
      fi
    done

A release is not normally expected to reach the 1,000-PR limit.

Review each PR's title, body, labels, changed files, and linked issue context. Classify it as:

  • Yes — repairs incorrect behavior, a regression, crash, compatibility problem, or documentation defect relevant to the release.
  • No — feature, refactor, cleanup, dependency refresh, or other change not needed to correct the release.
  • Unclear — insufficient evidence or meaningful backport risk; ask the user.

Deduplicate PRs found through both audits.

Report and label

Present the complete audit before changing GitHub labels:

PRTitleAuthorNVBug(s)Bug fix?cherry-pick-<VERSION> present?Recommendation

Use these recommendation values and sort the table in this order:

  1. Needs label — confirmed release-relevant bug fix.
  2. Unknown — requires user judgment.
  3. No action needed — not a release-relevant bug fix.

Use — when no NVBug is known. Also list NVBugs with no linked PR. Ask the user to confirm which recommended PRs should receive the missing label. After confirmation, apply it:

for pr in <APPROVED_NUMBERS>; do
  gh pr edit "$pr" --repo NVIDIA/Model-Optimizer --add-label "cherry-pick-$VERSION"
done

Do not label unmerged PRs, PRs not based on main, or candidates classified Unclear without explicit approval. Re-run the audit table after edits so it reflects the final label state.

Step 3 — Fetch pending PRs

Use the GitHub search API to list PRs that have the cherry-pick label but not cherry-pick-done, sorted by merge date ascending:

gh api "search/issues?q=repo:NVIDIA/Model-Optimizer+is:pr+is:merged+base:main+label:cherry-pick-<VERSION>+-label:cherry-pick-done&sort=updated&order=asc&per_page=50" \
  --jq '.items[] | [.number, .title, .pull_request.merged_at] | @tsv' \
  | sort -t$'\t' -k3

Present the list to the user before proceeding.

Step 4 — Set up the release branch

Check out release/<VERSION>, creating it from the remote if it doesn't exist locally:

git fetch origin release/<VERSION>
git checkout release/<VERSION>

Step 5 — Get merge commit SHAs

All PRs are squash-merged, so each has a single-parent commit. Retrieve the SHA for each PR:

gh pr view <NUM> --repo NVIDIA/Model-Optimizer --json mergeCommit --jq '.mergeCommit.oid'

Step 6 — Cherry-pick in merge order

Cherry-pick each commit with -s (DCO sign-off). GPG signing is handled automatically by the repo's git config.

git cherry-pick -s <SHA>

On conflict: Tell the user which PR caused the conflict and ask them to fix it, then continue:

git cherry-pick --continue

Step 7 — Create a PR to the release branch

Push the cherry-picks to a new branch and open a PR targeting release/<VERSION>. The PR title lists every cherry-picked PR number. The body uses ## Cherry-picked PRs as the only heading with one - #<NUM> bullet per PR — no titles, no links, no extra text.

git checkout -B cherry-picks/release-<VERSION>
git push -u origin cherry-picks/release-<VERSION>

gh pr create \
  --title "[Cherry-pick] PRs #<NUM1> #<NUM2> ..." \
  --base release/<VERSION> \
  --head cherry-picks/release-<VERSION> \
  --body "$(cat <<'EOF'
## Cherry-picked PRs

- #<NUM1>
- #<NUM2>
...
EOF
)"

Step 8 — Apply cherry-pick-done label

Add the cherry-pick-done label to every PR that was successfully cherry-picked:

for pr in <NUM1> <NUM2> ...; do
  gh pr edit $pr --repo NVIDIA/Model-Optimizer --add-label "cherry-pick-done"
done

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.