test(plugin): validate agent integration manifests in CI

[Sean Watson (seanwat-msft)]

Summary

Adds automated validation for the agent integration manifests introduced in PR 70 and rebased onto the root manifest layout from PR 72.

Value add

Manifest drift, marketplace submission-policy failures, and plugin discovery regressions now fail before merge instead of surfacing during installation or submission.

Usage impact

There is no runtime behavior change. Contributors can run npm install once and npm test to validate skills, manifests, marketplace policy, and local plugin discovery.

What changed

• Validate the root Agent Plugins manifest plus Claude and Cursor manifests against pinned published schemas.
• Check names, versions, skill paths, skill metadata, and marketplace entries remain aligned across every adapter.
• Guard against legacy nested manifests shadowing the canonical root manifest during Awesome Copilot intake.
• Check the canonical manifest meets Awesome Copilot's license and keyword submission policy.
• Run Vally skill lint, plugin discovery, and native Claude and Gemini validators in GitHub Actions.
• Remove the unsupported author.url field from the Cursor manifest.

Known deferred

• Codex, GitHub Copilot, Grok, and Kimi do not currently expose stable public schemas for every manifest used here. Those adapters receive JSON parsing and cross-manifest consistency coverage instead.

Verified: npm ci, npm test, npm audit --audit-level=moderate, Claude plugin validation, Gemini extension validation, and the replacement GitHub Actions run all pass.

[Chris (chcaru)]

heads up this is going to go red as soon as it picks up main. #72 moved the canonical manifest to the repo root and deleted .github/plugin/plugin.json, but the test still points canonicalManifestPath at .plugin/plugin.json and still lists the .github/plugin copy in pluginManifestPaths. nothing textually conflicts so git merges it clean and github still shows mergeable, but i merged main into the branch locally and ran it: three of the six fail on ENOENT. repointing canonical at plugin.json and dropping the two dead entries put it back to 6/6.

same staleness in the workflow triggers, paths still watches .plugin/** and .github/plugin/** but never root plugin.json, so after 72 the canonical manifest is the one file that can change without this job running at all.

on the awesome-copilot side, the thing i'd most want pinned is that their intake resolves the manifest by first match over .github/plugin/plugin.json, then .plugin/plugin.json, then plugin.json. if either nested copy ever comes back the listing silently drops to the old warnings, and nothing here would catch it since the current test asserts those paths exist. a guard asserting those two are absent would stop 72 regressing. probably worth also asserting what their publicSubmission policy checks at listing time, license non-empty and keywords capped at 10 matching ^[a-z0-9-]+$ and under 30 chars, since the agent-plugins schema itself doesn't enforce any of that. we're at 7 valid keywords today so it's purely a guard.

one real drift the alignment test misses: skills/rayfin-getting-started/SKILL.md still carries metadata.version: "0.1.0" while every manifest says 0.3.0. the manifests all get compared to each other but never to the skill's own frontmatter.

last thought, worth an install smoke in here? npx plugins discover . is one line and it's already what you were checking by hand. what surprised me doing 72 is that you can delete every plugin.json in the tree and copilot still installs the skill fine, but delete skills/ and it installs zero skills while every manifest stays perfectly valid. so manifest correctness and the plugin actually loading turn out to be fairly independent, and awesome-copilot runs its own install gate at submission regardless.