nemoclaw-maintainer-evening

par nvidia

Exécute la passation de fin de journée pour le mainteneur de NemoClaw. Vérifie la progression des cibles de version, enregistre les retardataires pour un bump automatique post-tag, génère une passation QA…

npx skills add https://github.com/nvidia/nemoclaw --skill nemoclaw-maintainer-evening

NemoClaw Maintainer Evening

Close the day with one release candidate, one cumulative documentation change, and a clear handoff. Tagging is optional. Report tag creation first, then let the tag skill finish post-tag follow-through.

See PR-REVIEW-PRIORITIES.md for the daily cadence and the release-train policy for release rules.

1. Select the Target Version

Use the maintainer's exact vX.Y.Z when supplied. Otherwise, read the current target and show its merged and open work:

node --experimental-strip-types --no-warnings \
  .agents/skills/nemoclaw-maintainer-day/scripts/version-target.ts
node --experimental-strip-types --no-warnings \
  .agents/skills/nemoclaw-maintainer-day/scripts/version-progress.ts vX.Y.Z

Do not silently convert the answer into a patch, minor, or major bump. If nothing shipped, ask whether to stop without a tag.

2. Finish One Cumulative Documentation Change

Inspect the current Docs / Post-Merge Catch-Up state. The Pi workflow owns documentation catch-up for merged changes. Continue its managed draft PR when one exists. If no managed PR exists and the release entry is the only missing change, use one direct documentation-only PR.

The documentation PR must contain all required documentation for every merged change selected for the release and one canonical dated entry headed ## vX.Y.Z. Follow docs/CONTRIBUTING.md and obtain its required independent documentation writer review. Do not create a separate release-entry PR when the active cumulative docs PR can carry it.

Merge the documentation PR before selecting the tag candidate. A docs-only merge does not start another Docs / Post-Merge Catch-Up run. Preserve the merged PR, its final commit, its merge commit, and the final automated refresh coverage commit for the tag session.

If another product merge lands before candidate selection, decide whether it belongs in this release. When it does, update the cumulative documentation change first. When it does not, the tag skill may keep an earlier planned candidate that remains on main; later managed documentation work does not invalidate that candidate.

When an included merge changes the candidate after planning, generate a new exact-version plan after its documentation merges.

3. Show the Release Handoff

Show:

  • merged work in vX.Y.Z;
  • open PRs and issues still carrying vX.Y.Z;
  • the canonical release entry;
  • the cumulative docs PR, coverage commit, later commits and PRs, review state, and check state;
  • known image-publication state; and
  • the newest full E2E status, SHA, age, and URLs.

Open labeled items are post-tag planning state, not a tag blocker. State which items are expected to move to the next target, but do not perform label writes here.

4. Cut the Tag When Requested

Load nemoclaw-maintainer-cut-release-tag and pass the exact version. That skill owns:

  • the exact-version plan and candidate;
  • the required release entry, documentation coverage decision, and image evidence;
  • the maintainer's focused, full, or proceed E2E choice;
  • ../nemoclaw-release-vX.Y.Z/release-brief.md;
  • the exact confirmation phrase; and
  • signed tag creation and remote readback.

Do not run a full E2E suite automatically. Do not ask for confirmation until the release brief is complete and the maintainer has reviewed it.

5. Complete the Handoff

After tag readback, report:

  • tag and candidate commit;
  • plan and release-brief paths;
  • documentation coverage, maintainer decision, and image evidence URLs; and
  • E2E decision and exception reason, if any.

Then let nemoclaw-maintainer-cut-release-tag monitor the automatic post-tag workflows, draft the Announcement, and report lkg state. A post-tag failure does not change tag success.

Hard Rules

  • Never cut a tag without the maintainer's exact confirmation phrase.
  • Never bypass the release entry, documentation coverage decision, or applicable GHCR evidence.
  • Never make a different candidate stale merely because main advanced or a later documentation PR opened.
  • Never delay the tag-cut report for post-tag work. Continue the same task after that report.

Plus de skills de nvidia

compileiq-debug
nvidia
Utilisez quand quelque chose ne va pas : Search() bloque, toutes les évaluations retournent INVALID_SCORE, les scores ne s'améliorent pas, chaque configuration retourne le même nombre, erreurs ptxas…
create-github-pr
nvidia
Créer des pull requests GitHub en utilisant l'interface en ligne de commande gh. Utiliser lorsque l'utilisateur souhaite créer une nouvelle PR, soumettre du code pour révision, ou ouvrir une pull request. Mots-clés de déclenchement -…
nemoclaw-maintainer-cross-issue-sweep
nvidia
Analyse les autres problèmes ouverts pour trouver ceux qu’une PR donnée pourrait également corriger ou casser accidentellement. Génère des opportunités de correctifs adjacents et des risques de contradiction avec fichier:ligne…
fhir-basics
nvidia
Apprend aux agents comment fonctionnent les API FHIR R4, quelles ressources sont disponibles, comment les interroger avec des paramètres de recherche, et comment analyser correctement tous les formats de réponse…
compileiq-validate-result
nvidia
Utiliser APRÈS qu'une recherche soit terminée et AVANT de réclamer un accélérateur ou d'expédier un ACF. Charge le CSV dump_results, extrait les K meilleurs candidats (mono-objectif)…
changelog-audit
nvidia
Auditer le CHANGELOG.md de Warp avant une publication : récupérer les entrées perdues, trier par impact utilisateur, affiner le langage des entrées, ajuster les retours à la ligne et (en mode branche de publication) mettre à jour la comparaison…
maintain-dynamic-plugins
nvidia
Maintenir les chargeurs de plugins dynamiques NeMo Relay, les manifestes, les SDK natifs Rust, le protocole worker gRPC, le SDK worker Python, la documentation, les tests et la couverture du workflow de publication
dgx-diagnose
nvidia
Diagnostiquer les problèmes courants du DGX Station GB300 — plantages CUDA, ciblage incorrect du GPU, bugs de conteneur vLLM/SGLang, problèmes d'état MIG, erreurs NVLink/Fabric Manager,…