nemoclaw-contributor-update-dependencies

Audits and implements dependency upgrades as semantic migrations across upstream releases.

Updated Aug 1, 2026
One-click install
npx skills add https://github.com/Army161/NemoClaw --skill nemoclaw-contributor-update-dependencies-army161
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: nemoclaw-contributor-update-dependencies
Source: https://github.com/Army161/NemoClaw/tree/main/.agents/skills/nemoclaw-contributor-update-dependencies
Command: npx skills add https://github.com/Army161/NemoClaw --skill nemoclaw-contributor-update-dependencies-army161

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) and references (resource) components.

What problem does it solve? Version bumps often hide breaking changes, silent default shifts, and supply-chain risks that a simple lockfile edit never surfaces. This Skill turns every dependency upgrade into a structured migration audit so nothing changes in NemoClaw without evidence of what changed upstream and where it is consumed downstream. ## Core Features & Use Cases - Release-by-release ledger: Enumerates every adjacent release range in the upgrade gap and audits release notes, commits, source diffs, and upstream tests per range instead of collapsing them into one diff. - Contract tracing and concern ledger: Maps changed upstream contracts (CLI, config, API, lifecycle, packaging) to direct and indirect NemoClaw consumers, then records each risk in a structured concern ledger with severity, disposition, and verification evidence. - Deterministic evidence collection: Ships a hardened Python collector that gathers Git and GitHub release evidence with frozen executable identities, bounded subprocesses, and integrity-checked non-promisor clones. - Use Case: When upgrading OpenShell or OpenClaw across multiple tags, run the audit to produce a per-range ledger, implement migrations in release order, and hand off a reviewable PR with resolved concerns and remaining external gates. ## Quick Start Use the nemoclaw-contributor-update-dependencies skill to audit and implement the upgrade of OpenShell from the current pinned version to the latest release.

Frequently Asked Questions about nemoclaw-contributor-update-dependencies

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I safely upgrade a dependency across multiple releases?

Treat the upgrade as a migration: enumerate every adjacent release range, read release notes, commits, source diffs, and upstream tests per range, then map changed contracts to downstream consumers. Implement migrations in release order with a regression test per concern.

What is a dependency concern ledger?

A concern ledger is a structured record of every migration risk found during the audit. Each entry names the release range, old and new contract, downstream consumer, failure mode, severity, disposition such as migrate or guard, and verification evidence.

Why is a version-only bump not enough for dependency upgrades?

Release notes can omit silent default changes, packaging shifts, or contracts the downstream project relies on accidentally. A version-only bump skips source and test analysis, so breaking behavior can ship undetected behind green aggregate tests.

Does the release ledger collector work with shallow or partial Git clones?

No. The collector rejects shallow, partial, and promisor clones, replace refs, grafts, and alternate object databases before collecting evidence. It requires a self-contained non-promisor clone and runs strict full object-integrity checks.

Can this workflow modify the upstream dependency repository?

No. The mutation boundary restricts all changes to the NemoClaw repository. Upstream repositories, registries, issue trackers, and pull-request queues are treated as read-only evidence sources.

How are untagged upstream commits handled as upgrade targets?

Untagged targets are bound to an advertised upstream branch ref rather than raw commit lookup, since GitHub can expose fork and pull-request objects. The range is labeled latest-tag to candidate-commit and re-audited against the final tag before shipping.