mcpbeat

Nemoclaw Maintainer Verify Stale

nvidia/nemoclaw-maintainer-verify-stale

Verifies whether stale NVIDIA/NemoClaw bug reports still reproduce on the latest tag. Use when maintainers ask to verify stale issues, reproduce old bugs on latest, or drain the bug backlog. Uses native Issue Type, canonical labels, local/Brev reproduction, by-design detection, confidence scoring, approved Project updates, and redacted verdict comments; never auto-closes.

30k tokens
context cost
the whole folder, loaded on every use
7
files
instructions only
0
copies elsewhere
how many repositories repackaged it
22044
stars on the repo
on the repository, not the skill itself

Install

one command, takes just this skill from the repository
npx skills add https://github.com/NVIDIA/NemoClaw --skill nemoclaw-maintainer-verify-stale

What comes with it

116 195 bytes besides the instruction
reference/brev-provisioning.md
reference/by-design.md
reference/candidate-selection.md
reference/environment-and-reproducer.md
reference/reproduction-rubrics.md
reference/scoring-comments-and-logging.md

The instruction itself

5 sections, as written by the author

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

<!-- SPDX-License-Identifier: Apache-2.0 -->

NemoClaw Maintainer — Verify Stale Issues

Automates the maintainer loop: choose an old issue whose native Issue Type is Bug, verify whether it still reproduces on the latest NemoClaw tag, then prepare an evidence-backed Project/comment write set for maintainer approval. It never closes issues automatically and never substitutes labels for Issue Type, lifecycle, or resolution.

Progress checklist

Copy this checklist and update it as you work:

Verify-stale progress:
- [ ] Select issue(s), latest tag, and reported version
- [ ] Apply skip/idempotency/active-discussion filters
- [ ] Classify environment, provider, and bug class
- [ ] Extract or synthesize a reproducer
- [ ] Verify preconditions and try local-first if eligible
- [ ] If Brev is needed, get plan approval before provisioning
- [ ] Validate the reproducer on baseline, then verify latest
- [ ] Check by-design/static-analysis branch when behavior was removed
- [ ] Score, redact, draft, and self-verify comment links
- [ ] Re-check issue state, apply the accepted Project/comment write set
- [ ] Append activity log entry

Workflow

  • Select candidates and versions. Read reference/candidate-selection.md. Use it for single-issue mode, batch mode, latest-tag detection, filters, idempotency, active-discussion handling, and reported-version parsing.
  • Classify and prepare. Read reference/environment-and-reproducer.md. Use it for CPU/GPU/provider/bug-class classification, safe API-key handling, reproducer extraction, dependency checks, Brev auth, and local-first verification.
  • Stop for approval before cost. In batch mode, present one issue's plan and wait for maintainer approval before provisioning Brev.
  • Provision and install. If local-first does not settle the issue, read reference/brev-provisioning.md. Use it for Brev reuse/provisioning, reset, baseline/latest installs, dependency bootstrap, and brev exec footguns.
  • Run the verification rubric. Read reference/reproduction-rubrics.md. Use it to validate baseline behavior, retry with a synthesized reproducer if needed, run latest, handle architectural drift, and branch for performance or rebuild-cycle bugs.
  • Check intentional changes. If the symptom targets removed/deprecated behavior, read reference/by-design.md. Use static evidence to recommend Project Status Won't Fix, then request explicit approval for the Project/comment write set.
  • Score, propose, apply, and log. Read reference/scoring-comments-and-logging.md. Use it for confidence scoring, redaction, concise templates, authorization, issue-state race checks, approved Project 199 movement, infra failures, and activity logging.

Non-negotiables

  • Never auto-close an issue. Verdict names belong in comments and logs, not labels.
  • Never write a Project field, assignment, or public comment before the maintainer accepts that write set.
  • Never put API keys on a command line. Use the file-based pattern in environment-and-reproducer.md.
  • Never post unredacted transcripts, issue excerpts, synthesized scripts, internal hostnames, email addresses, or tokens.
  • Never post a comment with broken markdown links or tag-drifting file:line citations. Re-run cited commands and link-check at least one rendered link per comment section.
  • Never use Brev for unsupported platforms or integration-token issues in v1.
  • Keep comments concise: default to 200–300 words for fixed/by-design, 100–200 for inconclusive, and 30–80 for still-reproduces.

Reference map

| Need | Read |

|---|---|

| Candidate query, filters, version parser | reference/candidate-selection.md |

| Environment classification, credentials, reproducer, preconditions, local-first | reference/environment-and-reproducer.md |

| Brev box reuse/provision, reset, installs, dependency bootstrap | reference/brev-provisioning.md |

| Baseline/latest matching, synth-repro, drift, performance, rebuild-cycle | reference/reproduction-rubrics.md |

| Static by-design branch and proposed Won't Fix Project state | reference/by-design.md |

| Score, redact, authorize, comment, Project update, infra handling, log | reference/scoring-comments-and-logging.md |

How to use it

Copy the folder

Take nvidia/nemoclaw-maintainer-verify-stale from the repository into ~/.claude/skills for personal use, or into .claude/skills inside a project.

Check the name does not clash

The agent identifies a skill by the name field in its header. Two skills with the same name cannot sit side by side — one of them will be ignored.