nemoclaw-maintainer-evening

bởi nvidia

Chạy quy trình bàn giao người bảo trì cuối ngày cho NemoClaw. Kiểm tra tiến độ mục tiêu phiên bản, ghi lại các tác vụ chậm trễ để tự động tăng post-tag, tạo bàn giao 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.

Thêm skills từ nvidia

compileiq-debug
nvidia
Sử dụng khi có điều gì đó không ổn: Search() bị treo, tất cả các đánh giá đều trả về INVALID_SCORE, điểm số không cải thiện, mọi cấu hình đều trả về cùng một số, lỗi ptxas…
create-github-pr
nvidia
Tạo pull request GitHub bằng cách sử dụng gh CLI. Sử dụng khi người dùng muốn tạo PR mới, gửi mã để xem xét, hoặc mở pull request. Từ khóa kích hoạt -…
nemoclaw-maintainer-cross-issue-sweep
nvidia
Quét các vấn đề đang mở khác để tìm những vấn đề mà một PR nhất định có thể sửa hoặc vô tình làm hỏng. Đưa ra các cơ hội sửa lỗi liền kề và rủi ro mâu thuẫn với file:dòng…
fhir-basics
nvidia
Dạy các tác nhân cách hoạt động của API FHIR R4, những tài nguyên có sẵn, cách truy vấn chúng với tham số tìm kiếm, và cách phân tích chính xác tất cả các định dạng phản hồi…
compileiq-validate-result
nvidia
Sử dụng SAU KHI tìm kiếm hoàn tất và TRƯỚC KHI yêu cầu tăng tốc hoặc gửi ACF. Tải tệp CSV dump_results, trích xuất các ứng viên top-K (đơn mục tiêu)…
changelog-audit
nvidia
Kiểm tra Warp CHANGELOG.md trước khi phát hành: khôi phục các mục bị mất, sắp xếp theo tác động người dùng, tinh chỉnh ngôn ngữ mục, xuống dòng và (chế độ nhánh phát hành) so sánh bump…
maintain-dynamic-plugins
nvidia
Duy trì các bộ nạp plugin động NeMo Relay, tệp kê khai, SDK gốc Rust, giao thức worker gRPC, SDK worker Python, tài liệu, kiểm thử và phạm vi quy trình phát hành
dgx-diagnose
nvidia
Chẩn đoán các sự cố thường gặp của DGX Station GB300 — lỗi CUDA, nhắm sai GPU, lỗi container vLLM/SGLang, vấn đề trạng thái MIG, lỗi NVLink/Fabric Manager,…