Skip to content

fix(skills): stop three skills claiming data NCM doesn't return #80

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
Cesar-M-Diaz merged 1 commit into from
Oct 26, 2026
Merged

fix(skills): stop three skills claiming data NCM doesn't return #80

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions skills/ns-node-upgrade/SKILL.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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 <pkg>@<version> 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.
Expand Down
5 changes: 3 additions & 2 deletions skills/ns-replace-package/SKILL.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand All @@ -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 <pkg> version`, then `npm view <pkg> 'time[<version>]'`). 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.
Expand All @@ -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 <pkg> version` and `npm view <pkg> 'time[<version>]'` — 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.
Expand Down
5 changes: 3 additions & 2 deletions skills/ns-upgrade-package/SKILL.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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 <pkg> version` prints the version the `latest` dist-tag points to (`npm view <pkg> dist-tags` lists the others).
- If the user specified a target version explicitly, use that instead of latest.

### 3. Assess Workspace Usage
Expand All @@ -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.
Expand All @@ -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 <pkg> 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.
Expand Down
Loading