From 96604bc2bf205656a591779e33d92d2f9de1c69f Mon Sep 17 00:00:00 2001 From: Cesar-M-Diaz Date: Mon, 26 Oct 2026 13:53:41 +0100 Subject: [PATCH] fix(skills): stop three skills claiming data NCM doesn't return ns-replace-package listed obfuscation, author risk and malware as NCM module risks. NCM has none of those: its only security check is vulnerability. The example list now names real risk checks. Its maintenance signal, and ns-upgrade-package's latest version, came from NCM, whose latest can trail npm by weeks; both now come from npm. ns-node-upgrade checked "target-Node incompatibilities if NCM reports them". NCM has no such data. The step now reads the uses-deprecated-node-apis score from allScores, where it keeps its name, compares engines.node with the target, and says neither is a full compatibility check. Versions come from the lockfile: a range makes npm view print every matching version, and a workspace: spec fails the whole getPackageVersions call. --- skills/ns-node-upgrade/SKILL.md | 4 ++-- skills/ns-replace-package/SKILL.md | 5 +++-- skills/ns-upgrade-package/SKILL.md | 5 +++-- 3 files changed, 8 insertions(+), 6 deletions(-) diff --git a/skills/ns-node-upgrade/SKILL.md b/skills/ns-node-upgrade/SKILL.md index 214b3ee..0facefe 100644 --- a/skills/ns-node-upgrade/SKILL.md +++ b/skills/ns-node-upgrade/SKILL.md @@ -56,14 +56,14 @@ Return a response with these sections: - Update CI/CD configuration (GitHub Actions `node-version`, Dockerfile `FROM node:X`, etc.). - Run tests with the new version and watch for deprecation warnings. - Check for incompatible native modules (`node-gyp` rebuild if needed). -6. **Dependency Compatibility** — read direct deps from `package.json` (`dependencies`, `devDependencies`, `optionalDependencies`) and call `getPackageVersions` with `{name, version}` entries to check target-Node incompatibilities if NCM reports them. +6. **Dependency Compatibility** — list direct deps from `package.json` (`dependencies`, `devDependencies`, `optionalDependencies`) and take each one's installed version from the lockfile, not the `package.json` range. Leave out `workspace:`, `file:`, `link:` and git specs: one of them fails the whole `getPackageVersions` call. Call `getPackageVersions` with `{name, version}` entries. NCM doesn't say which Node.js versions a package supports. In each result's `allScores`, the entry named `uses-deprecated-node-apis` lists the deprecated Node.js APIs that version uses, which may warn or break on the target line: report the ones with `pass: false`. (`moduleRisks` lists failing checks without their names.) Also compare each dependency's `engines.node` (`npm view @ engines`, with the exact version: a range prints every matching version) with the target. Say that neither is a full compatibility check; the test suite on the target version is. 7. **Verification** — how to confirm the upgrade was successful (`node --version`, test suite, check for `DeprecationWarning`s in output). ### 5. Re-detect if Needed If the user asks about a specific version mid-conversation, re-run the detection in step 2 (`package.json` engines, `.nvmrc`, `.node-version`, or `node --version`) to refresh the current version. ## Tools -- `getPackageVersions` — check direct dependencies for known incompatibilities with target Node version. +- `getPackageVersions` — NCM's `uses-deprecated-node-apis` score (in `allScores`) for each direct dependency, at its lockfile version. ## Guardrails - The release schedule table from `fetch-node-releases.cjs` or the injected host table is authoritative. Do not override LTS names, EOL dates, or latest patch versions with training-data values. diff --git a/skills/ns-replace-package/SKILL.md b/skills/ns-replace-package/SKILL.md index 232c94c..8cfe721 100644 --- a/skills/ns-replace-package/SKILL.md +++ b/skills/ns-replace-package/SKILL.md @@ -11,7 +11,7 @@ description: >- ### 2. Fetch NCM Data for the Target Package - Call `getPackageQuality` for the package being replaced. -- Document: vulnerabilities (severity + title), license, module risks flagged by NCM (e.g. install scripts, obfuscation, author risk, malware), quality scores. +- Document: vulnerabilities (severity + title), license, module risks flagged by NCM (e.g. deprecated, install scripts, eval, unsafe regexps, deprecated Node APIs), quality scores. - Use these findings as the objective reasons why replacement is warranted. ### 3. Propose Alternatives @@ -26,7 +26,7 @@ Present a comparison table or ranked list with these columns: - NCM vulnerability status - License - NCM module risks -- Maintenance signal (latest version age, if available from NCM) +- Maintenance signal: the latest version and its age, from the npm registry (`npm view version`, then `npm view 'time[]'`). NCM's `latest` can trail npm by weeks. - Why it is or isn't recommended Lead with the strongest recommendation and explain the tradeoff clearly. @@ -42,6 +42,7 @@ For the top recommended alternative, provide: ## Tools - `getPackageQuality` — call once for the target package and once for each proposed alternative. Do not recommend an alternative without querying NCM for it first. +- `npm view version` and `npm view 'time[]'` — the latest published version and when it was published, from the npm registry. ## Guardrails - Do not invent unpublished or fictional alternatives. Only recommend packages that genuinely exist and are relevant to the use case. diff --git a/skills/ns-upgrade-package/SKILL.md b/skills/ns-upgrade-package/SKILL.md index 6b73171..e6768ac 100644 --- a/skills/ns-upgrade-package/SKILL.md +++ b/skills/ns-upgrade-package/SKILL.md @@ -11,7 +11,7 @@ description: >- ### 2. Fetch NCM Data - Call `getPackageQuality` with the package name and current version (or `latest` if not installed) to retrieve vulnerability severity, known issues, license, and quality scores. -- The tool returns the latest available version as well — record it. +- A call for the installed version doesn't return the latest one, and NCM's `latest` can trail npm by weeks. Get the latest version from the npm registry: `npm view version` prints the version the `latest` dist-tag points to (`npm view dist-tags` lists the others). - If the user specified a target version explicitly, use that instead of latest. ### 3. Assess Workspace Usage @@ -29,7 +29,7 @@ Apply SemVer heuristics to assess risk: Return a response with these sections: 1. **Current State** — detected version, source (package.json / lockfile / not found), and workspace usage count. -2. **Latest Version** — the version NCM reports as latest. +2. **Latest Version** — the version the npm registry's `latest` dist-tag points to. 3. **NCM Security & Quality** — any vulnerabilities (severity + title), license, module risks flagged by NCM. If NCM data is unavailable, say so explicitly. 4. **SemVer Risk Assessment** — change type (major / minor / patch), risk level, and reasoning based on workspace usage and dependents. 5. **Breaking Changes** — use SemVer heuristics and any NCM-flagged issues. Do NOT fabricate specific changelog entries. Direct the user to the package's official CHANGELOG.md or release notes for the authoritative list. @@ -42,6 +42,7 @@ Return a response with these sections: ## Tools - `getPackageQuality` — query NCM for vulnerability severity, known issues, license, and quality scores for a single package. +- `npm view version` — the latest published version, from the npm registry. ## Guardrails - Never fabricate changelog details, breaking changes, or migration guides. NCM data does not include changelogs. Use SemVer heuristics and workspace usage data to assess risk instead, and point the user to official release notes.