[PaulBoye-py]

Summary

Fixes the CLI so it installs the current skills from the Cloudinary skills repo again, and raises the Node.js requirement to 22 for next-cloudinary v7.

Problem

The CLI clones the skills repo when it creates a project and copies cloudinary-next, cloudinary-docs and cloudinary-transformations into it. It falls back to copies bundled in the CLI only if the clone fails.

On 18 September the skills repo moved its skills into category folders (skills/frameworks/…, skills/platform/…). The CLI only looks in skills/<name>, so it no longer finds any of the three. It then silently uses the bundled copies, even though the clone worked. Two of the bundled copies (docs and transformations) are already out of date.

Changes

• findSkillSourceDir also looks in each category folder under skills/, and only accepts a folder that contains a SKILL.md.
• If the clone works but a skill still isn't found, the CLI now prints a warning before using the bundled copy, so a future layout change doesn't go unnoticed.
• engines.node raised from >=18.0.0 to >=22.0.0, and the README requirement changed from "current LTS" to "Node.js 22 or later". The template now uses next-cloudinary v7 (chore: upgrade next-cloudinary to v7 create-cloudinary-next-template#1), which requires Node.js 22.
• Refreshed the bundled cloudinary-docs and cloudinary-transformations copies from the skills repo.

The bundled cloudinary-next copy is unchanged (it matches the skills repo's current version). The v7 update to that skill is in cloudinary-devs/skills#28. With this fix, the CLI picks it up from the skills repo as soon as it's merged; the bundled copy can be refreshed afterwards.

Testing

node cli.js --headless --cloudName demo --projectName … --aiTools claude --aiTools cursor --installDeps false:

• Before: all three installed skills matched the bundled copies; docs and transformations differed from the skills repo.
• After: all six installed copies (.claude/skills and .agents/skills) are identical to the skills repo's main. The MCP config files are still written.

Not changed

The release workflow still uses Node.js 20, which is end-of-life. It's left for a separate change, since it can only be tested by running a release.

[strausr]

engines doesn't enforce the Node.js version by default but is only a warning, or nothing at all, unless they've turned on engine-strict.
We can have the CLI check process.versions.node and stop or warn with a clear message

[PaulBoye-py]

Thank you @strausr, and a great point too! The CLI now checks process.versions.node at startup and stops with a clear message on anything below 22, before any prompts or files. I went with stopping rather than a warning, since the template needs Node 22 for next-cloudinary v7, but happy to switch it to a warning if you prefer.

[strausr]

This sits inside for (const targetRoot of targetRoots). If the user picks Claude plus Cursor/Copilot/Generic, there are two target folders (.claude/skills and .agents/skills), so every missing skill gets the same warning twice.

Instead we can work out sourceDir for each skill once, before the targetRoots loop, and warn there.

[PaulBoye-py]

That's a good catch, thank you. Skill sources are now resolved once before the target-folder loop, so each missing skill is reported once. I tested it with Claude plus Cursor against a skills repo with one skill removed: two warnings before, one now, with identical installed files.

[strausr]

Need to update lockfle to match version

[PaulBoye-py]

Updated, thank you! The lockfile's root version and engines now match package.json. It drifts because each release bumps the version in both files, but the release commit only includes package.json and CHANGELOG.md (all four beta release commits show this). Would you like me to add package-lock.json to the @semantic-release/git assets in a separate PR, so it stays in sync after each release?