fix: use package license for skills

[maxchang3]

🔗 Linked issue

resolves #2043

🧭 Context

Currently, the logic for retrieving a skill’s license only checks the frontmatter.

As a result, when a skill does not specify a license there, the system displays a misleading "No license specified" warning, even if the parent package already defines a valid license.

📚 Description

This PR improves license handling in skills.ts by retrieving and passing the package license as a fallback when a skill does not specify its own license.

---

(A related question: if a skill's license differs from the package's license, should we explicitly surface this (or even treat it as a warning)?)

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
npmx.dev	Ready	Preview, Comment	Mar 12, 2026 2:13pm

2 Skipped Deployments

Project	Deployment	Actions	Updated (UTC)
docs.npmx.dev	Ignored	Preview	Mar 12, 2026 2:13pm
npmx-lunaria	Ignored		Mar 12, 2026 2:13pm

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ All tests successful. No failed tests found.

📢 Thoughts on this report? Let us know!

[coderabbitai]

📝 Walkthrough

Walkthrough

The validateSkill function in server/utils/skills.ts was modified to accept an optional packageLicense parameter. The fetchSkillsList function now retrieves the package license from npm for the specified version. When constructing a SkillListItem, the license field prioritises frontmatter.license, then falls back to packageLicense. License-based warnings are only triggered when neither source provides a license. In-code comments were added to document the fallback logic.

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	The code changes directly address issue #2043 by implementing package license fallback logic in validateSkill and fetchSkillsList, preventing misleading 'No license specified' warnings.
Out of Scope Changes check	✅ Passed	All changes in server/utils/skills.ts are directly related to resolving license fallback handling for skills, with no unrelated modifications present.
Description check	✅ Passed	The pull request description clearly relates to the changeset, explaining the problem (license warnings despite package-level licenses) and the solution (fallback to package license).

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

📝 Coding Plan for PR comments

• Generate coding plan

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[marlonwq]

Great addition with the fallback logic!

Regarding your question: I definitely think we should surface it when a skill's license differs from the package's license.

As discussed in #1826, license transparency is a major pain point and surfacing these mismatches prevents 'legal traps' for users who assume the entire package follows the root license. A subtle UI warning or just a 'license override' badge would be a huge DX win.

[ghostdevv]

@marlonwq suggestion makes sense! will mark this as draft while it's being worked on 🙏 @maxchang3 let me know if you'd like any help, or don't have time to take it on right now 🙏

[maxchang3]

@ghostdevv Hi, since the warning messages are still hardcoded (see #2049), would it make more sense to add a new warning after that fix lands? Or we can do this in a follow-up PR, since this one only affects the internal warning generation logic.

I'm also happy to adapt this to this PR.