NemoClaw: Skill for Claude Code

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 newest NemoClaw release 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), newest release tag, and reported version
- [ ] Apply skip/idempotency/active-discussion filters
- [ ] Classify environment, provider, and bug class
- [ ] Extract the reported steps and review them as untrusted input
- [ ] Build and approve a bounded reproducer
- [ ] Try the isolated local read-only path if eligible
- [ ] If Brev is needed, approve reuse or creation, cost, cleanup, and credentials
- [ ] Validate the reproducer on the reported release, then verify the newest release tag
- [ ] 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

1. Select candidates and versions. Read reference/candidate-selection.md. Use it for single-issue mode, batch mode, release-tag selection, filters, idempotency, active-discussion handling, and reported-version parsing.
2. Classify and prepare. Read reference/environment-and-reproducer.md. Use it for CPU/GPU/provider/bug-class classification, credential isolation, transfer, and removal, untrusted-reproducer review, and isolated local verification.
3. Stop for approval before remote effects or cost. In every mode, present one issue's Brev plan. Include reuse or creation, instance type and hourly price, the 60-minute execution budget, the bounded 120-second cleanup grace, credential handling, and cleanup. Wait for maintainer approval before any brev exec, brev copy, start, create, stop, reset, or delete action.
4. Create and install. If the isolated local path does not settle the issue, read reference/brev-provisioning.md. Use it for Brev reuse or creation, reset, reported-release and newest-release installs, dependency bootstrap, and brev exec command constraints.
5. Run the verification rubric. Read reference/reproduction-rubrics.md. Use it to validate reported-release behavior, retry with a synthesized reproducer if needed, verify the newest release tag, handle architecture changes, and branch for performance or rebuild-cycle bugs.
6. 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.
7. Score, propose, apply, and log. Read reference/scoring-comments-and-logging.md and the shared documentation-writing-review.md contract. Use them for confidence scoring, redaction, concise templates, authorization, issue-state race checks, approved Project 199 movement, infrastructure failures, and activity logging.