Ejecuta cualquier Skill en Manus
con un clic

Ejecuta cualquier Skill en Manus con un clic

eunomai-dependency-upgrade

Estrellas0

Forks0

Actualizado1 de julio de 2026 a las 22:02

Universal hygiene for adding or upgrading third-party dependencies — pin via lockfile, scan for known CVEs (SCA) before merging, read the changelog, take breaking changes incrementally, run the tests, and track licenses. Use when adding a new dependency, bumping versions, or responding to a security advisory. Anchored to OWASP A03:2025 (Software Supply Chain) and SLSA.

Instalación

Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.

Ejecutar en Manus

Fuente

grojof

grojof/eunomai

Abrir repositorio de GitHub Ver repositorios del creador

Descarga

Ejecutar en Manus

Ocupaciones relacionadasSOC

Basado en la clasificación ocupacional SOC

Desarrolladores de softwareOcupaciones informáticas y matemáticas·SOC 15-1252

SKILL.md

readonly

name	eunomai-dependency-upgrade
description	Universal hygiene for adding or upgrading third-party dependencies — pin via lockfile, scan for known CVEs (SCA) before merging, read the changelog, take breaking changes incrementally, run the tests, and track licenses. Use when adding a new dependency, bumping versions, or responding to a security advisory. Anchored to OWASP A03:2025 (Software Supply Chain) and SLSA.

eunomai-dependency-upgrade

Open-source makes up the majority of modern codebases, so dependencies are a primary risk surface. This is the universal hygiene for changing them — anchored to OWASP A03:2025 Software-Supply-Chain Failures and SLSA. It does not replace your package manager — it's the checklist around it.

Before adding a new dependency

Do you need it? Prefer the standard library or a few lines over a dependency. Fewer deps = smaller attack surface.
Vet it: maintained (recent commits/releases), reputable author, healthy usage, and an acceptable license for your project.
Check it's clean: run an SCA / CVE scan (e.g. npm audit, osv-scanner, pip-audit — or the scanner/registry the project's rules designate) before committing it.

When upgrading

Pin via a lockfile and commit it — deliberate, reproducible versions; upgrade on purpose, not by drift.
Read the changelog / release notes. Note breaking changes and deprecations.
One major at a time. Don't jump several majors at once; upgrade, build, test, repeat.
Scan again (SCA). Confirm the new version (and its transitive deps) has no known critical/high CVE; if one exists, check exploitability before shipping. Deciding to ship anyway is a risk acceptance — record the waiver (CVE id, rationale, revisit date) where the project keeps decisions (an ADR, or the location its rules designate).
Run the full test suite. Treat a dependency upgrade like any other change — green tests before merge.
Track licenses. Record/respect the dependency's license (an SBOM — SPDX/CycloneDX — captures name, version, supplier, and license); a new dep must not introduce an incompatible license.

Responding to a security advisory

When a CVE is published for a dependency you use: identify affected versions, upgrade to the patched release (or apply the documented mitigation), scan, test, and ship. An up-to-date lockfile + SBOM makes "are we affected?" a lookup, not an investigation.

Boundary

Universal hygiene only — the policy (which CVE severity blocks a release, approved registries, SLSA level) is the project/org's call, declared in its rules, not here.

Más de este repositorio

mismo repositorio

eunomai-living-docs

grojof/eunomai

Refresh a project's user-facing docs (root README + docs/) toward eunomai's v2 standard — Diátaxis as a lens via a `type` frontmatter field, a knowledge-domain coverage lens (the six KDD domains), an OKF-routable substrate (frontmatter + path-as-identity + a product-shaped README map), doc-set profiles by repo destination (library, API, CLI, framework, firmware, app — or custom), and a deterministic frontmatter gate. Use when docs have drifted, after shipping a feature, or when docs-check reports drift. Project-docs only (may create ADRs from interview answers; never edits existing ones).

2026-07-090

eunomai-onboard

grojof/eunomai

Cold-start orchestrator that applies eunomai to a new or existing project. Use when bringing a foreign project up to eunomai's standards — analyze it, assess what already exists (coexistence-first), establish/restructure docs (or create them), seed conventions (CLAUDE.md, OpenSpec config, permissions, hooks — each skippable), audit existing skills, then hand off. One-shot and dispensable; orchestrates the pillars, does not reimplement them.

2026-07-090

eunomai-skill-finder

grojof/eunomai

Trust-gated steward for a project's skills. Use when you need a capability and want to adopt/create a skill safely, when a third-party skill should be vetted before use, or when asked to audit existing skills. Discovers candidates, applies a trust gate (security veto + judgment), adopts/improves/creates via skill-creator, and records per-skill provenance. Best-effort floor-raiser, not a security guarantee.

2026-07-010

eunomai-secure-coding

grojof/eunomai

Universal secure-coding directives anchored to the OWASP Top 10:2025 and CWE Top 25. Use proactively while writing or changing code that handles input, auth, data, secrets, files, network calls, or dependencies — to avoid injection, broken access control, crypto and auth failures, SSRF, and unsafe deserialization. Writing-time guidance; for a diff audit use /security-review, for runtime blocking see safe-controls.

2026-07-010

diagnosing-bugs

grojof/eunomai

Diagnosis loop for hard bugs and performance regressions. Use when the user says "diagnose"/"debug this", or reports something broken/throwing/failing/slow.

2026-06-250

name	eunomai-dependency-upgrade
description	Universal hygiene for adding or upgrading third-party dependencies — pin via lockfile, scan for known CVEs (SCA) before merging, read the changelog, take breaking changes incrementally, run the tests, and track licenses. Use when adding a new dependency, bumping versions, or responding to a security advisory. Anchored to OWASP A03:2025 (Software Supply Chain) and SLSA.

eunomai-dependency-upgrade

Before adding a new dependency

Do you need it? Prefer the standard library or a few lines over a dependency. Fewer deps = smaller attack surface.
Vet it: maintained (recent commits/releases), reputable author, healthy usage, and an acceptable license for your project.
Check it's clean: run an SCA / CVE scan (e.g. npm audit, osv-scanner, pip-audit — or the scanner/registry the project's rules designate) before committing it.

When upgrading

Pin via a lockfile and commit it — deliberate, reproducible versions; upgrade on purpose, not by drift.
Read the changelog / release notes. Note breaking changes and deprecations.
One major at a time. Don't jump several majors at once; upgrade, build, test, repeat.
Scan again (SCA). Confirm the new version (and its transitive deps) has no known critical/high CVE; if one exists, check exploitability before shipping. Deciding to ship anyway is a risk acceptance — record the waiver (CVE id, rationale, revisit date) where the project keeps decisions (an ADR, or the location its rules designate).
Run the full test suite. Treat a dependency upgrade like any other change — green tests before merge.
Track licenses. Record/respect the dependency's license (an SBOM — SPDX/CycloneDX — captures name, version, supplier, and license); a new dep must not introduce an incompatible license.

Responding to a security advisory

Boundary

Universal hygiene only — the policy (which CVE severity blocks a release, approved registries, SLSA level) is the project/org's call, declared in its rules, not here.