Cross-skill version coherence: unpinned @icp-sdk/core installs resolve to incompatible majors

Problem

skills/wallet-integration/SKILL.md:60 installs nothing pinned:

npm i @dfinity/oisy-wallet-signer @dfinity/utils @dfinity/zod-schemas @icp-sdk/canisters @icp-sdk/core zod

Run today, that resolves to:

add @icp-sdk/core 4.2.3        <- two majors below every other skill
add @icp-sdk/canisters 3.1.0   <- downgraded from 3.6.0
add @dfinity/utils 4.0.3       <- downgraded from 4.2.1

The same skill's Prerequisites section (:55-57) states @icp-sdk/core (>= 5.0.0), @dfinity/utils (>= 4.2.0), @icp-sdk/canisters (>= 3.5.0). The install command violates all three of its own stated constraints.

Cause

@dfinity/oisy-wallet-signer 6.0.0 regressed its peer dependencies backwards:

oisy	peer @icp-sdk/core	peer @dfinity/utils	peer @icp-sdk/canisters
4.1.0	^5	^4.1	^3.2
4.1.3	^5	^4.2.1	^3.2
6.0.0 (latest)	^4	~4.0.3	~3.1.0

The skill was written correctly against oisy 4.1.x. Because the install line is unpinned it now takes 6.0.0, which drags the whole tree back to core 4.

Impact: two skills that cannot be used in the same project

• internet-identity → @icp-sdk/auth 8.0.3 → peer @icp-sdk/core@^5
• wallet-integration → oisy 6.0.0 → peer @icp-sdk/core@^4

Any app doing II login and wallet integration — a very common combination — cannot produce a valid install tree. Forcing core ^5 with the current line fails:

npm error code ERESOLVE
npm error Found: @icp-sdk/core@5.4.0
npm error Could not resolve dependency:
npm error peer @icp-sdk/core@"^4" from @dfinity/utils@4.0.3

The whole surface can be coherent at core 5

Pinning oisy below its regressed major resolves everything together:

npm i '@dfinity/oisy-wallet-signer@^4.1.3' @dfinity/utils @dfinity/zod-schemas \
      @icp-sdk/canisters '@icp-sdk/core@^5' @icp-sdk/auth zod

add @icp-sdk/core 5.4.0       add @icp-sdk/auth 8.0.3      add @icp-sdk/signer 5.6.3
add @icp-sdk/canisters 3.6.0  add @dfinity/utils 4.2.1     add @dfinity/oisy-wallet-signer 4.1.3

vetKeys and bindgen sit on the same tree: @icp-sdk/vetkeys 0.5.0 depends on core ^5.4.0, and bindgen's generated output type-checks clean (strict, skipLibCheck: false) against both core 5.4.0 and 6.1.0.

Also wrong, same class

skills/icp-cli/references/binding-generation.md:89:

@icp-sdk/core starts at version 5.x — there is no 0.x or 1.x release. Do not guess a lower version.

The published line is 1.0.0-beta.0…5 → 4.0.0…4.2.3 (stable) → 5.x → 6.x. So it does not start at 5, 1.x prereleases exist, and — the part that matters — 6.x is published but nothing else supports it yet, so the sentence invites someone to take latest and hit ERESOLVE against @icp-sdk/auth. (The move to ^6 is tracked separately in #365 — do not action it here.)

Rule to adopt

1. Pin every @icp-sdk/core mention explicitly to ^5. Never leave it unpinned in an install command.
2. Pin @dfinity/oisy-wallet-signer to ^4.1.3 (below the regressed 6.0.0) until it supports core ^5 again.
3. Say why ^5 and not latest, so the next person doesn't "helpfully" bump it.

Scope

• skills/wallet-integration/SKILL.md — pin the install line; reconcile with Prerequisites
• skills/icp-cli/references/binding-generation.md — pin, and fix the :89 sentence
• skills/icp-cli/references/dfx-migration.md — already pinned ^5.0.0; bump bindgen floor to ^0.4.0
• skills/icp-cli/SKILL.md:115 — same core wording
• skills/vetkeys/SKILL.md:25 — already ^5.4; confirm and keep

Upstream ask

@dfinity/oisy-wallet-signer 6.0.0's peer regression looks unintentional (a major bump that moves down a major on core, and tightens two peers to ~). Worth raising with that team — if 6.x is meant to be the core-5 line, its peers need correcting.

Read the install and prerequisite sections in skills/wallet-integration/SKILL.md, then inspect the referenced lines in skills/icp-cli/references/binding-generation.md, skills/icp-cli/references/dfx-migration.md, skills/icp-cli/SKILL.md, and skills/vetkeys/SKILL.md. Check the package peer versions and existing pins before aligning the documented commands and explanations. Done means the scoped files consistently describe a resolvable core 5 dependency tree without changing the separately tracked core 6 work in #365.