fix(kyberforge): correct field classification and fill provenance gaps in plugin-author and marketplace-author

## Why

The manifest-fields tables in both skills used imprecise labels ("CC-only",
"Copilot-only") that conflated two distinct reasons a field appears in only
one manifest: platform constraint (the other tool does not support the field
at all) versus repo convention (both tools support it, but the scaffold places
it in one manifest by design). This caused agents to treat convention
boundaries as hard platform constraints, producing unnecessary errors when
updating manifests for dual-tool repos.

Provenance was also incomplete: sources.md files were missing entries for
sources that had been consulted and were already contributing to SKILL.md
and manifest-fields.md content, making the evidence chain unverifiable.

## Implementation Notes

Field classification now uses three explicit categories — shared, platform
(one tool does not support the field), and convention (both tools support it;
scaffold places it in one manifest by design). The distinction matters because
convention fields may legitimately appear in the other manifest when there is
a deliberate reason; platform fields may not.

New gotchas added to plugin-author: agent files silently ignore hooks,
mcpServers, and permissionMode frontmatter; claude plugin tag --push requires
a clean working tree; --dry-run preview before tagging; --strict flag on
validate. New gotchas in marketplace-author: metadata object as Copilot CLI
canonical location for top-level fields; strict: false for dual-tool plugins;
sha takes precedence over ref for pinning; --strict flag on validate.

tests/ removed from plugin-author because new-plugin.sh has no branching
logic warranting a bats suite at this stage.

## Impact

Skill prompt changes only — no runtime code affected. Agents using these
skills will now correctly distinguish convention from constraint when deciding
which manifest to update for a given field.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

plugins/kyberforge/skills/marketplace-author/SKILL.md

@@ -7,14 +7,16 @@ description: >
   the marketplace version", "update the description for Y"). Always updates
   both .claude-plugin/marketplace.json and .github/plugin/marketplace.json in
   the same pass. Out of scope: plugin scaffold and configuration — use
-  /plugin-author for that. Does not manage marketplace registration with
-  Claude Code or Copilot CLI.
+  /plugin-author for that. Does not run `claude plugin marketplace add` or
+  equivalent CLI registration commands — only manages `marketplace.json`
+  entries.
 allowed-tools: Bash Read Write Edit
 metadata:
   category: factory
   source_keys:
     - context7-websites-code-claude
     - claude-code-plugins-docs
+    - context7-github-en-copilot
     - github-cli-plugin-reference
     - github-plugins-marketplace
     - github-plugins-finding-installing
@@ -31,8 +33,8 @@ metadata:
 - `name` must be kebab-case. Reserved prefixes (`anthropic-*`, `claude-*`, `agent-skills`, `official-claude-plugins`) are rejected by the validator.
 - The `plugins[]` array order is not semantically significant, but maintain it consistently — add new entries at the end.
 - For Copilot CLI, the canonical marketplace.json location is `.github/plugin/marketplace.json`. Claude Code also reads `.claude-plugin/marketplace.json`. Both are equivalent; this repo maintains both files in sync.
-
-Read `references/manifest-fields.md` for the full field reference and source type shapes before editing any file.
+- Copilot CLI places top-level `description` and `version` under a `metadata` object (`metadata.description`, `metadata.version`). Claude Code accepts them at the top level. For dual-tool repos, use the `metadata` form — it is valid in both tools.
+- Set `"strict": false` on a plugin entry to allow relaxed schema validation for that entry. This is the right choice for plugins distributed as `.claude-plugin/` directories that also serve Claude Code — it prevents Copilot CLI from failing on CC-specific fields that are not in the Copilot schema.
 
 ## Route
 
@@ -70,8 +72,10 @@ Create the file with the following structure (fill in the values from prerequisi
 {
   "name": "<marketplace-name>",
   "owner": { "name": "<owner-name>", "email": "<owner-email>" },
-  "description": "<marketplace-description>",
-  "version": "0.1.0",
+  "metadata": {
+    "description": "<marketplace-description>",
+    "version": "0.1.0"
+  },
   "plugins": [
     {
       "name": "<plugin-name>",
@@ -82,7 +86,7 @@ Create the file with the following structure (fill in the values from prerequisi
 }
 ```
 
-Omit `"email"` if not provided. Omit `"version"` from plugin entries unless the user specifies one (see Gotchas).
+Omit `"email"` if not provided. Omit `"metadata.version"` if the user does not want a pinned catalog version. The `metadata` object is the Copilot CLI canonical location for top-level description and version — Claude Code accepts both `metadata`-nested and top-level forms; use `metadata` for dual-tool repos.
 
 ### Step 2 — Write `.github/plugin/marketplace.json`
 
@@ -106,6 +110,8 @@ Confirm you have:
 - [ ] Source type and source value (see source type branching below)
 - [ ] Version (optional; omit for git-sourced plugins)
 
+If you need details on a specific source type shape or per-entry optional fields, read `references/manifest-fields.md`.
+
 ### Source type branching
 
 If the user has not specified a source type, ask:
@@ -127,7 +133,7 @@ Source shapes per type:
 ```json
 "source": { "source": "github", "repo": "owner/repo" }
 ```
-Add `"ref": "<branch-or-tag>"` inside the object if the user specifies a branch or tag.
+Add `"ref": "<branch-or-tag>"` inside the object if the user specifies a branch or tag. Add `"sha": "<commit-sha>"` if pinning to an exact commit — `sha` takes precedence over `ref` when both are present.
 
 **Git URL:**
 ```json
@@ -155,6 +161,8 @@ The full entry added to `plugins[]`:
 
 Include `"version": "<version>"` at the entry level only when the source is npm or when the user explicitly requests a pinned version in the catalog.
 
+Include `"strict": false` when the plugin is a dual Claude Code / Copilot CLI plugin — this prevents Copilot from rejecting CC-specific fields in the plugin directory.
+
 ### Step 1 — Read both files
 
 Read `.claude-plugin/marketplace.json` and `.github/plugin/marketplace.json`. Verify they are identical. If they differ, stop and report the divergence — do not proceed until the user resolves it.
@@ -205,6 +213,8 @@ Follow the **VALIDATE** flow.
 
 Run this flow when an entry exists in `plugins[]` and the intent is to change one or more fields.
 
+If you need to verify a field name or source type shape, read `references/manifest-fields.md`.
+
 ### Step 1 — Read the current entry
 
 Read `.claude-plugin/marketplace.json`. Show the current state of the target entry so the user can confirm the fields to change.
@@ -226,9 +236,11 @@ Follow the **VALIDATE** flow.
 Run `claude plugin validate .` from the repo root:
 
 ```bash
-cd <repo-root> && claude plugin validate .
+claude plugin validate .
 ```
 
+Add `--strict` to promote warnings to errors — recommended in CI.
+
 Report the output. If validation fails, describe the specific error and what needs to be fixed. Do not attempt to auto-fix validation errors unless the fix is unambiguous (e.g. a trailing comma that violates JSON syntax); otherwise, describe the fix and ask the user to confirm.
 
 Validation checks include: `marketplace.json` schema compliance, duplicate plugin names, source path traversal, and version mismatches.