@vibe-agent-toolkit/vat-development-agents 0.1.33 → 0.1.34-rc.2

package/dist/.claude/plugins/marketplaces/vat-skills/CHANGELOG.md

@@ -7,6 +7,38 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+### Added
+- **Skill-claude-plugin recognition in `vat audit`.** Introduces the **skill-claude-plugin** artifact shape — a skill that self-publishes as a Claude plugin by co-locating `.claude-plugin/plugin.json` alongside its root `SKILL.md`. Audit now emits independent `ValidationResult` entries for each surface (one `agent-skill`, one `claude-plugin`) instead of reporting only the plugin and silently ignoring the skill. The skill remains platform-agnostic; the graduation to skill-claude-plugin adds Claude-specific packaging only. See [`docs/architecture/skill-packaging.md`](docs/architecture/skill-packaging.md) for the full packaging-shape terminology (standalone skill / skill-claude-plugin / claude-plugin / claude-marketplace).
+- **`SKILL_CLAUDE_PLUGIN_NAME_MISMATCH`** validation code (default `warning`). Fires on the plugin result when a skill-claude-plugin's `plugin.json.name` disagrees with the co-located `SKILL.md` frontmatter `name`. The skill is authoritative; the plugin manifest is a distribution wrapper and should match unless the plugin is intentionally namespaced (in which case use `validation.severity` or `validation.allow`).
+- **Self-contained Claude Code plugin support in `vat claude plugin build`.**
+  Adopters can now bundle commands, hooks, agents, MCP servers, scripts, raw
+  plugin-local `SKILL.md` files, and author-supplied `plugin.json` metadata from a
+  per-plugin `plugins/<name>/` directory. The entire directory is tree-copied
+  verbatim (respecting `.gitignore`). Pre-existing pool-to-plugin skill selectors
+  (`marketplace.plugins[].skills`) are preserved — a plugin can still declare
+  `skills: "*"` or `skills: [names]` to import pool skills (built by
+  `vat skills build`) into its bundle. The skills stream is unchanged: `vat skills
+  build` continues to produce `dist/skills/<name>/` only. New schema fields on
+  marketplace plugin entries: `source` (path override, default `plugins/<name>`)
+  and `files[]` (compiled-artifact mappings). The 5-phase plugin build pipeline
+  is deterministically ordered (discovery → tree-copy → pool-skill import →
+  `files[]` → merged `plugin.json`). YAML summary adds `commandsCopied`,
+  `hooksCopied`, `agentsCopied`, `mcpCopied`, `treeFilesCopied`,
+  `explicitFilesCopied` per plugin. Case-sensitivity mismatches between declared
+  plugin names and on-disk dirs now fail the build to catch Linux-CI drift.
+
+### Changed
+- `vat audit` directory-entry detection uses a new `enumerateSurfaces()` helper that returns every manifest present at the directory root, replacing single-result detection in the multi-surface case. Single-surface directories retain their legacy single-validator dispatch, including the marketplace-with-co-located-plugin collapse.
+- `packages/cli/src/commands/audit/hierarchical-output.ts` comments standardized on the new terminology: the pattern previously documented as "standalone plugin skill (no skills subdir)" is now called **skill-claude-plugin**.
+- Upgraded `vibe-validate` and `@vibe-validate/cli` dev dependencies from `^0.19.1` to `^0.19.4`.
+
+### Documentation
+- New reference doc `docs/architecture/skill-packaging.md` enumerates the four packaging shapes with layouts and applicable validation.
+- `docs/README.md` gains a "Validation & Quality Framework" section indexing the three stance docs (`skill-quality-and-compatibility.md`, `validation-codes.md`, `skill-smell-philosophy.md`).
+- New `docs/CLAUDE.md` and `docs/architecture/CLAUDE.md` agent navigators pull in each directory's README via `@README.md` and add agent-only guidance for audit/validation work.
+- Root `/CLAUDE.md` "Questions?" section now links to directories rather than README files — child CLAUDE.md files auto-trigger and pull in their README once, avoiding the previous double-read pattern.
+- `packages/cli/CLAUDE.md` gains a "Validation Framework References" section.
+
 ## [0.1.33] - 2026-04-21
 
 ### Added

package/dist/.claude/plugins/marketplaces/vat-skills/plugins/vibe-agent-toolkit/.claude-plugin/plugin.json

@@ -1,8 +1,8 @@
 {
   "name": "vibe-agent-toolkit",
-  "description": "Development agents and skills for building with vibe-agent-toolkit",
-  "version": "0.1.33",
+  "version": "0.1.34-rc.2",
   "author": {
     "name": "vibe-agent-toolkit contributors"
-  }
+  },
+  "description": "Development agents and skills for building with vibe-agent-toolkit"
 }

package/dist/.claude/plugins/marketplaces/vat-skills/plugins/vibe-agent-toolkit/skills/vat-adoption-and-configuration/SKILL.md

@@ -84,7 +84,6 @@ claude:
       plugins:
         - name: my-plugin
           description: "What this plugin does"
-          skills: "*"
 
 rag:
   stores:

package/dist/.claude/plugins/marketplaces/vat-skills/plugins/vibe-agent-toolkit/skills/vat-skill-distribution/SKILL.md

@@ -182,15 +182,14 @@ claude:
       plugins:
         - name: my-plugin             # installable unit
           description: My plugin description
-          skills: "*"                  # all discovered skills
 ```
 
-The `skills:` section discovers SKILL.md files via include/exclude globs. The `claude:` section defines how skills are packaged into plugins. Each marketplace has `owner` and `plugins` fields (strict schema — no extra fields).
+The top-level `skills:` section drives standalone skill builds (output: `dist/skills/`). The `claude:` section defines plugins, which are assembled from their own `plugins/<name>/` directories (plugin-local skills under `plugins/<name>/skills/**/SKILL.md`). Each marketplace has `owner` and `plugins` fields (strict schema — no extra fields).
 
 **Naming convention:** marketplace = org identity (e.g. `acme`), plugin = this package
 (e.g. `acme-tools`). Registers as `my-plugin@my-marketplace` in Claude's plugin registry.
 
-### Multiple skills in one package
+### Multiple skills in one plugin
 
 List all skills in `vat.skills` for npm discoverability:
 
@@ -201,18 +200,16 @@ List all skills in `vat.skills` for npm discoverability:
 }
 ```
 
-Use a selector in the plugin config to include matching skills:
+Each skill lives as a subdirectory of the plugin under `plugins/<name>/skills/<skill>/SKILL.md`:
 
-```yaml
-plugins:
-  - name: my-plugin
-    description: Linting and testing skills
-    skills:
-      - "my-linting"
-      - "my-testing"
+```
+plugins/my-plugin/
+  skills/
+    my-linting/SKILL.md
+    my-testing/SKILL.md
 ```
 
-Or use `"*"` to include all discovered skills in the plugin.
+All plugin-local skills found under `plugins/<name>/skills/` are packaged into the plugin automatically — no per-plugin selector is needed or supported. Skill names must be globally unique across all plugins.
 
 ## Step 3: Build
 
@@ -264,7 +261,6 @@ claude:
       plugins:
         - name: my-plugin
           description: My plugin description
-          skills: "*"
       publish:
         github:
           repo: owner/repo          # GitHub repo to publish to
@@ -406,3 +402,13 @@ All `vat` commands in this skill work with these alternatives.
 ## Future: Zero-Dependency Postinstall (Option B)
 
 A planned improvement: `vat build` would bundle the plugin install logic into `dist/postinstall.js` — a fully self-contained script with no npm dependencies. The postinstall script would become simply `node ./dist/postinstall.js`. This eliminates `vibe-agent-toolkit` as a runtime dependency entirely, reducing install footprint for end users. Until then, Option C (runtime `vibe-agent-toolkit` dep) is the correct approach.
+
+## Full-plugin authoring (commands, hooks, agents, MCP)
+
+VAT supports bundling any Claude Code plugin asset — not just skills. Drop the plugin
+under `plugins/<name>/` in the same native layout Claude expects. VAT tree-copies
+everything (minus `skills/` and `.claude-plugin/`), merges author `plugin.json` with
+VAT-owned identity fields, and applies any `files[]` mappings for artifacts built
+outside the plugin dir.
+
+See [docs/guides/marketplace-distribution.md](resources/marketplace-distribution.md) section "Full-plugin authoring".

package/dist/.claude/plugins/marketplaces/vat-skills/plugins/vibe-agent-toolkit/skills/vat-skill-distribution/resources/marketplace-distribution.md

@@ -0,0 +1,427 @@
+# Marketplace Distribution
+
+**Guide for building, validating, and publishing Claude plugin marketplaces.**
+
+## Overview
+
+A Claude plugin marketplace is a Git repository containing `.claude-plugin/marketplace.json` and plugin directories. Marketplaces are the distribution unit for Claude Code (via `/plugin marketplace add`) and Cowork (via GitHub App sync). VAT supports three modes of marketplace management.
+
+## Three Marketplace Modes
+
+| Mode | Description | VAT commands |
+|------|-------------|-------------|
+| **Built** | Source repo with skills → `vat build` → publish to `claude-marketplace` branch | `vat build`, `vat validate`, `vat claude marketplace publish` |
+| **Separate repo** | Source repo → `vat build` → publish to a different Git repo | Same as Built (remote configured in YAML) |
+| **Manual/native** | The repo IS the marketplace — no build step | `vat validate` (with config) or `vat claude marketplace validate` (without config) |
+
+## Distribution Surfaces
+
+Custom skills and plugins **do not sync across Claude surfaces**. Each surface is independent:
+
+| Surface | Source | Scope | Marketplace format? |
+|---------|--------|-------|---------------------|
+| **Claude Code** | Git repo with `marketplace.json` | Self-service install | Yes |
+| **Cowork (claude.ai)** | Admin UI → GitHub App sync from private repo | Org-wide, admin-controlled | Yes (same format) |
+| **Skills API** | `POST /v1/skills` multipart upload | Workspace-wide | No (direct API upload) |
+| **Claude Code (managed)** | `managed-settings.json` via MDM | Per-machine, IT-managed | Yes (marketplace ref in settings) |
+
+Public and private GitHub marketplaces use the **same format**. The only difference is authentication (private repos require `GITHUB_TOKEN` or `GH_TOKEN` for auto-updates).
+
+## Marketplace Structure
+
+```
+marketplace-repo/           # or claude-marketplace branch
+├── .claude-plugin/
+│   └── marketplace.json    # marketplace manifest (required)
+├── plugins/
+│   └── plugin-name/
+│       ├── .claude-plugin/
+│       │   └── plugin.json # plugin manifest (required)
+│       ├── skills/
+│       │   └── skill-name/
+│       │       ├── SKILL.md
+│       │       └── references/
+│       ├── commands/       # slash commands (*.md)
+│       ├── agents/         # agent definitions (*.md)
+│       └── hooks/          # hooks.json
+├── CHANGELOG.md            # marketplace changelog
+├── README.md               # marketplace "storefront" for GitHub
+└── LICENSE                  # required for distribution
+```
+
+## Versioning Strategy
+
+**Marketplace version is the distribution version.** One version for the whole marketplace.
+
+| Artifact | Versioned? | Required? | Source |
+|----------|-----------|-----------|--------|
+| Marketplace | Yes | Yes (error if missing) | `package.json` or config |
+| Plugin | Yes | Yes (error if missing) | Defaults to marketplace version |
+| Skill | No | N/A | Tracked by marketplace version |
+
+Skills are not independently versioned by VAT. The SKILL.md frontmatter spec has no version field. Skill changes are tracked at the marketplace level.
+
+Plugin version defaults to the marketplace version when not explicitly set. The top-level version defaults to `package.json` when available.
+
+## Branch Convention
+
+**Default publish branch: `claude-marketplace`** — analogous to GitHub Pages' `gh-pages`.
+
+- Source code and SDLC on `main` (tests, lint, CI, PRs)
+- Built marketplace artifacts on `claude-marketplace` (clean, generated)
+- Extensible: `claude-marketplace-beta`, `claude-marketplace-next` for staging channels
+- Configurable via `publish.branch` in config or `--branch` flag
+
+**Default-branch-only surfaces:** Both Cowork (claude.ai) and Claude Enterprise GitHub sync read from the repository's **default branch only** — they cannot target a specific branch. This means the branch-based publish pattern (`claude-marketplace` / `claude-marketplace-next`) does not work for these surfaces.
+
+**Workaround: dedicated marketplace repo.** Create a separate repository where the default branch (`main`) IS the marketplace. Configure `publish.remote` to point to this repo:
+
+```yaml
+publish:
+  remote: https://github.com/org/my-marketplace-repo.git
+  branch: main
+```
+
+This keeps your source code and SDLC on the original repo while the marketplace repo contains only the published artifacts.
+
+**Enterprise lockdown:** `managed-settings.json` supports `ref` on marketplace sources:
+
+```json
+{
+  "strictKnownMarketplaces": [
+    { "source": "github", "repo": "acme/plugins", "ref": "claude-marketplace" }
+  ]
+}
+```
+
+## Configuration
+
+In `vibe-agent-toolkit.config.yaml`:
+
+```yaml
+version: 1
+
+claude:
+  marketplaces:
+    my-marketplace:
+      owner:
+        name: Your Name or Org
+      publish:
+        branch: claude-marketplace          # default
+        remote: origin                      # git remote name, or full URL for cross-repo publish
+        changelog: docs/marketplace-changelog.md
+        readme: docs/marketplace-readme.md
+        license: mit                        # SPDX identifier or file path
+        sourceRepo: false                   # optional linkback in commit metadata
+      plugins:
+        - name: my-plugin
+          description: What this plugin does
+          skills: "*"                       # or list: ["skill-a", "skill-b"]
+```
+
+### License field
+
+The `license` field accepts:
+- **SPDX identifier string** (e.g., `mit`, `apache-2.0`, `gpl-3.0`) — generates standard license text with owner name and current year
+- **File path** (e.g., `./LICENSE` or `docs/LICENSE-ENTERPRISE`) — copies the file as-is
+
+Strings are validated against known SPDX identifiers. Paths are distinguished by containing `/` or `.` characters.
+
+## Changelog
+
+Each marketplace maintains its own `CHANGELOG.md` following [Keep a Changelog](https://keepachangelog.com/) format. The marketplace release cadence may differ from source package releases.
+
+- Author maintains the changelog source file in the repo (path configured in YAML)
+- On publish, it's copied to `CHANGELOG.md` in the published tree
+- The `[Unreleased]` section is required for publish — the command refuses if empty
+- On publish, `[Unreleased]` is stamped with version + date
+- The changelog delta becomes the Git commit message body
+
+Categories: `Added`, `Changed`, `Removed`, `Fixed`, `Security`.
+
+## Publish Flow
+
+```bash
+# 1. Build marketplace artifacts
+vat build
+
+# 2. Validate everything
+vat validate
+
+# 3. Publish to claude-marketplace branch
+vat claude marketplace publish
+
+# Or dry-run first
+vat claude marketplace publish --dry-run
+```
+
+**What publish does:**
+
+1. Verifies `vat build` output exists
+2. Checks marketplace changelog has `[Unreleased]` content
+3. Composes the publish tree (marketplace artifacts + CHANGELOG.md + README.md + LICENSE)
+4. Creates a single squashed commit: `publish v{version}` with changelog delta as body
+5. Pushes to the configured branch/remote
+
+**Flags:**
+- `--dry-run` — compose and show diff, don't push
+- `--branch <name>` — override configured branch
+- `--force` — force-push (first publish or recovery only)
+
+**Commit history:** Each publish adds one commit. The `claude-marketplace` branch accumulates a clean release timeline — `git log` shows the version history of the marketplace.
+
+## CI/CD: Cross-Repo Publishing
+
+When publishing to a **separate repository** (via `publish.remote`), the default `GITHUB_TOKEN` in GitHub Actions is scoped to the source repo and cannot push to the target. You need a Personal Access Token (PAT) or fine-grained token with write access to the marketplace repo.
+
+**Setup:**
+
+1. Create a PAT with `contents: write` permission on the marketplace repo
+2. Store it as a repository secret (e.g., `MARKETPLACE_GITHUB_PUSH_TOKEN`)
+3. Expose it as `GH_TOKEN` in your workflow — `vat claude marketplace publish` uses `GH_TOKEN` (or `GITHUB_TOKEN`) to authenticate pushes
+
+```yaml
+# .github/workflows/marketplace-publish.yml
+- name: Publish marketplace
+  env:
+    GH_TOKEN: ${{ secrets.MARKETPLACE_GITHUB_PUSH_TOKEN }}
+  run: |
+    vat build
+    vat claude marketplace publish --branch main
+```
+
+**Why a separate token?** GitHub Actions' built-in `GITHUB_TOKEN` has repo-scoped permissions and cannot push to other repositories. This is a standard pattern for any cross-repo CI operation.
+
+## Validation
+
+### With config (`vat validate`)
+
+When marketplace config exists, `vat validate` orchestrates in dependency order:
+
+1. `resources validate` — links, frontmatter, schemas
+2. `skills validate` — SKILL.md structure, frontmatter
+3. `marketplace validate` — marketplace.json, plugin.json, structure
+
+Each layer fails fast — bad links block skill validation, bad skills block marketplace validation.
+
+### Without config (`vat claude marketplace validate`)
+
+Standalone validation for manual/native marketplaces. Uses the same discovery logic as `vat audit` but with **strict expectations** — this must be a valid marketplace:
+
+| Check | `vat audit` (liberal) | `marketplace validate` (strict) |
+|-------|----------------------|--------------------------------|
+| Missing version | Warning | Error |
+| Missing LICENSE | Ignored | Error |
+| Bad plugin.json | Warning | Error |
+| Missing README | Ignored | Warning |
+| Missing CHANGELOG | Ignored | Warning |
+| Bad SKILL.md | Warning | Error |
+
+```bash
+# Validate a marketplace directory or repo
+vat claude marketplace validate .
+vat claude marketplace validate path/to/marketplace
+```
+
+## Examples
+
+### Built mode: monorepo publishes to same repo
+
+```yaml
+# vibe-agent-toolkit.config.yaml
+claude:
+  marketplaces:
+    vat-skills:
+      owner:
+        name: vibe-agent-toolkit contributors
+      publish:
+        changelog: docs/marketplace-changelog.md
+        readme: docs/marketplace-readme.md
+        license: mit
+      plugins:
+        - name: vibe-agent-toolkit
+          description: Development agents and skills
+          skills: "*"
+```
+
+```bash
+vat build && vat validate && vat claude marketplace publish
+```
+
+Consumers install via:
+```
+/plugin marketplace add owner/repo#claude-marketplace
+```
+
+### Separate repo: private source, public marketplace
+
+```yaml
+# vibe-agent-toolkit.config.yaml in private source repo
+claude:
+  marketplaces:
+    acme-skills:
+      owner:
+        name: Acme Corp
+      publish:
+        remote: git@github.com:acme/acme-skills-marketplace.git
+        changelog: docs/marketplace-changelog.md
+        readme: docs/marketplace-readme.md
+        license: apache-2.0
+      plugins:
+        - name: acme-tools
+          description: Acme engineering tools
+          skills: "*"
+```
+
+### Manual/native: repo IS the marketplace
+
+No `vat build`, no publish. Author maintains `marketplace.json` and plugin directories directly. Validate with:
+
+```bash
+# With vibe-agent-toolkit.config.yaml
+vat validate
+
+# Without config
+vat claude marketplace validate .
+```
+
+## Testing Your Marketplace
+
+After publishing, test the marketplace locally before sharing with users. This flow validates the full consumer experience — clone, install, and skill loading.
+
+### Test flow
+
+```bash
+# 1. Add the marketplace (uses the published branch)
+claude plugin marketplace add owner/repo#claude-marketplace
+
+# 2. Install the plugin from the marketplace
+claude plugin install my-plugin@my-marketplace
+
+# 3. Validate the installed plugin
+claude plugin validate ~/.claude/plugins/cache/my-marketplace/my-plugin/<version>
+
+# 4. List plugins and verify status
+claude plugin list
+
+# 5. Start a new Claude Code session — skills should appear in /skill-name
+```
+
+### What to verify
+
+- **Marketplace add** succeeds and `known_marketplaces.json` shows the correct source
+- **Plugin install** resolves the correct version from plugin.json
+- **All skills** are present in the cache directory
+- **`claude plugin validate`** passes on the installed plugin
+- **`claude plugin list`** shows the plugin as enabled
+- **Skills load** in a new session (check the system reminder for skill names)
+
+### Updating after changes
+
+After publishing a new version:
+
+```bash
+# Update the marketplace cache
+claude plugin marketplace update my-marketplace
+
+# Update the installed plugin
+claude plugin update my-plugin@my-marketplace
+```
+
+### Known issues
+
+**Name collision on marketplace add (Claude Code v2.1.81):** If a marketplace with the same `name` field already exists (e.g., previously registered via npm), `claude plugin marketplace add` reports success but silently reuses the old source in `known_marketplaces.json`. The workaround is to remove the old marketplace first, then add:
+
+```bash
+claude plugin marketplace remove my-marketplace
+claude plugin marketplace add owner/repo#branch
+```
+
+Verify by checking `~/.claude/plugins/known_marketplaces.json` to confirm the source switched to `github`.
+
+**`claude plugin validate` rejects `$schema` key (Claude Code v2.1.81):** The marketplace validator treats `$schema` as an unrecognized key, even though Anthropic's own official marketplace uses it. This does not affect runtime behavior — the marketplace installs and works correctly. This is a Claude Code validation bug, not a marketplace authoring issue.
+
+
+## Full-plugin authoring
+
+`vat claude plugin build` ships any Claude Code plugin asset — not just skills. Drop the plugin under `plugins/<name>/` in the same native layout Claude Code expects, declare it in `vibe-agent-toolkit.config.yaml`, and `vat claude plugin build` assembles the output from that plugin's own directory. Pool skills (from the top-level `skills:` discovery) are still imported into the plugin via the `skills:` selector — the plugin directory and the pool skills are both sources, composed into one bundle.
+
+### Layout
+
+```
+plugins/<name>/
+  .claude-plugin/
+    plugin.json       # author-supplied metadata; VAT merges on top
+  commands/           # slash commands (*.md)
+  hooks/
+    hooks.json        # hook registry (JSON; parse-only validated)
+  agents/             # subagent definitions (*.md)
+  .mcp.json           # MCP server config (JSON; parse-only validated)
+  scripts/            # arbitrary scripts (tree-copied verbatim)
+  skills/             # plugin-local SKILL.md files — tree-copied verbatim
+```
+
+Everything under `plugins/<name>/` is tree-copied to `dist/.claude/plugins/marketplaces/<mp>/plugins/<name>/`, except:
+
+- `.claude-plugin/` — owned by the `plugin.json` merge-write (see "plugin.json merge")
+
+Tree-copy respects `.gitignore` (safe: `node_modules/`, build detritus never ship). `plugins/<name>/skills/` is just a regular tree-copied directory — drop raw `SKILL.md` files there and they ship as-is.
+
+### Minimum content — empty-plugin guard
+
+Every declared plugin must supply at least one of:
+
+- a `plugins/<name>/` directory on disk (or an alternate `source:` override pointing at one), **or**
+- a non-empty `files: [{ source, dest }, ...]` mapping, **or**
+- a non-empty `skills:` selector that matches at least one pool skill.
+
+A plugin with none of these is rejected with the empty-plugin guard.
+
+### `source` override
+
+```yaml
+claude:
+  marketplaces:
+    mp1:
+      owner: { name: Example }
+      plugins:
+        - name: my-plugin
+          skills: []
+          source: custom/path/to/my-plugin   # default: plugins/my-plugin
+```
+
+### `files[]` — compiled artifacts outside the plugin dir
+
+Use `files: [{ source, dest }]` to inject build artifacts (compiled hooks, generated configs) into the plugin output:
+
+```yaml
+plugins:
+  - name: my-plugin
+    skills: []
+    files:
+      - source: dist/hooks/compiled-hook.mjs   # relative to project root
+        dest: hooks/compiled-hook.mjs         # relative to plugin output dir
+```
+
+`dest` cannot escape the plugin output dir and cannot target `.claude-plugin/plugin.json` (owned by merge-write). Overwrites are allowed and logged at info level.
+
+### `plugin.json` merge rules
+
+VAT writes `.claude-plugin/plugin.json` last, merging the author's `.claude-plugin/plugin.json` (if present) with VAT-owned identity fields:
+
+- **VAT wins** on `name`, `version`, `author` (shallow replace — mismatches produce warnings, never errors).
+- **Author wins** on all other keys (`keywords`, `repository`, `homepage`, `license`, …).
+- **Description chain:** `config.description ?? author.description ?? "${name} plugin"`.
+- `version` falls back to the author's value when VAT has no version (no `package.json`).
+
+### Ordering contract
+
+`vat claude plugin build` runs per plugin in this order:
+
+1. Discovery + validators (case-match, `hooks.json`/`.mcp.json` parse, empty-plugin guard)
+2. Tree-copy `plugins/<name>/` verbatim (skips `.claude-plugin/`, respects `.gitignore`)
+3. Pool-skill import via the plugin's `skills:` selector (from `dist/skills/`)
+4. `files[]` mapping (may overwrite tree-copied files; logged at info)
+5. `.claude-plugin/plugin.json` merge-write (always last, always wins)
+
+**Run order:** `vat skills build && vat claude plugin build`. The plugin build reads pre-built pool skills from `dist/skills/` and raw plugin-local skills directly from `plugins/<name>/skills/`.

package/dist/generated/resources/skills/vat-adoption-and-configuration.js

@@ -7,7 +7,7 @@ export const meta = {
   description: "Use when starting a new VAT project, adding VAT to an existing repo, or orienting to \`vibe-agent-toolkit.config.yaml\`. Covers project setup, repo structure, package.json wiring, vibe-validate integration, and the npm postinstall hook."
 };
 
-export const text = "\n# VAT Adoption and Configuration\n\nThis skill covers the top-level orientation for adopting VAT in a project: installing the CLI, the overall shape of \`vibe-agent-toolkit.config.yaml\`, repo structure conventions, vibe-validate integration, and how npm postinstall wires plugin registration. Per-section deep-dives live in the sibling skills listed below.\n\n## Installing VAT\n\nVAT ships as the \`vibe-agent-toolkit\` npm package with a \`vat\` CLI:\n\n\`\`\`bash\n# Global install (most common during development)\nnpm install -g vibe-agent-toolkit\n\n# Or run without installing\nnpx vibe-agent-toolkit <command>\nbunx vibe-agent-toolkit <command>\n\n# As a runtime dependency (recommended for published packages that ship skills)\nnpm install --save vibe-agent-toolkit\n\`\`\`\n\nOnce installed, \`vat --help\` lists the top-level command groups. \`vat <group> --help\` and \`vat <group> <cmd> --help --verbose\` cover the rest.\n\n## Recommended Repo Structure\n\n\`\`\`\nmy-skills-project/\n├── package.json                        # includes \"vat\" block (see below)\n├── vibe-agent-toolkit.config.yaml      # single source of truth for VAT\n├── resources/\n│   ├── skills/                         # SKILL.md sources\n│   │   ├── SKILL.md                    # router skill (optional, for multi-skill bundles)\n│   │   └── my-skill.md\n│   └── content/                        # non-skill markdown (RAG, collections)\n├── agents/                             # TypeScript portable agents (optional)\n│   └── my-agent/\n│       ├── agent.yaml\n│       └── src/\n├── schemas/                            # JSON Schemas for resource collections\n├── docs/                               # project documentation\n└── dist/                               # generated (gitignored): vat build output\n\`\`\`\n\nThree conventions are load-bearing:\n\n1. **\`vibe-agent-toolkit.config.yaml\` at the project root** — VAT commands pick up this file when run from the project root or a subdirectory.\n2. **SKILL.md files live under \`resources/skills/\`** — any path works, but this one is what \`vat build\` and \`vat audit\` expect by default.\n3. **\`dist/\` is the only write target** — everything VAT generates goes there, and it\'s gitignored.\n\n## \`vibe-agent-toolkit.config.yaml\` Shape\n\n\`\`\`yaml\nversion: 1\n\nskills:\n  include: [\"resources/skills/SKILL.md\", \"resources/skills/*.md\"]\n  defaults:\n    linkFollowDepth: 2\n    excludeNavigationFiles: true\n    targets: [\'claude-code\']\n  config:\n    my-skill:\n      linkFollowDepth: 1\n\nresources:\n  collections:\n    docs:\n      include: [\"docs/**/*.md\"]\n      validation:\n        frontmatterSchema: \"schemas/doc.schema.json\"\n        mode: permissive\n\nclaude:\n  marketplaces:\n    my-marketplace:\n      owner: { name: \"my-org\" }\n      publish:\n        changelog: CHANGELOG.md\n        readme: README.md\n      plugins:\n        - name: my-plugin\n          description: \"What this plugin does\"\n          skills: \"*\"\n\nrag:\n  stores:\n    default:\n      db: .rag-db/\n      include: [\"docs/**/*.md\"]\n\`\`\`\n\nSections and the skills that own their details:\n\n| Section | Owning skill |\n|---|---|\n| Top-level structure, \`version\`, section orientation | this skill (\`vat-adoption-and-configuration\`) |\n| \`skills:\` (include, defaults, per-skill config, packagingOptions) | \`vibe-agent-toolkit:vat-skill-authoring\` |\n| \`resources:\` (collections, schemas, validation modes) | \`vibe-agent-toolkit:vat-knowledge-resources\` |\n| \`claude:\` (marketplaces, plugins, publish, owner) | \`vibe-agent-toolkit:vat-skill-distribution\` |\n| \`rag:\` (stores, embedding providers) | \`vibe-agent-toolkit:vat-rag\` |\n\nWhen adding to a section, load the owning skill rather than re-deriving the shape from this file.\n\n## Config lives at the VAT project root\n\nA VAT project is a directory that contains a \`vibe-agent-toolkit.config.yaml\`. That file is authoritative for the project: it defines \`resources\`, \`skills\`, \`claude\`, and (optionally) \`rag\`. Nothing outside the config contributes to its behavior — there is no ambient configuration, no inheritance from parent directories, and no merge with sibling configs.\n\nVAT commands (\`vat build\`, \`vat verify\`, \`vat skills validate\`, \`vat skills build\`) read the config at the directory they are invoked from. Run them from the project root or from a subdirectory, or pass \`--cwd <path>\` to point them at a specific project. If you run a lifecycle command from somewhere that has no config, it will not find one — there is no upward walk here.\n\n**Multiple \`vibe-agent-toolkit.config.yaml\` files in one git repository mean multiple distinct VAT projects.** Each project is independent: configs do not compose, do not merge, and do not inherit from one another. Running VAT from outside any project directory operates on a union of whatever projects it discovers, but each project\'s rules are applied only to its own skills — per-skill packaging overrides in \`project-a/vibe-agent-toolkit.config.yaml\` never affect skills under \`project-b/\`.\n\n\`vat audit\` is the one command that knowingly spans projects, and even there it does not compose: audit is a general-purpose read-only scan that you may point at any path, configured or not. When it encounters a SKILL.md inside a configured VAT project, it walks UP to that skill\'s nearest-ancestor \`vibe-agent-toolkit.config.yaml\` and applies **only** that skill\'s packaging rules (from its own project\'s \`skills.config.<name>\`) to the finding. This is display sanity, not federation — audit never merges config data across project boundaries.\n\nIn practice, prefer one \`vibe-agent-toolkit.config.yaml\` per git repository. Multiple configs in a single repo are reasonable only for:\n\n- Committed test harnesses or fixtures that define their own toy VAT projects (for VAT\'s own tests, or for an adopter\'s integration tests).\n- Genuinely unrelated projects that happen to share a monorepo and each ship their own skills.\n\nIf you are tempted to use nested configs to \"share\" or \"override\" settings across related skills, fold everything into one project-level config instead — that\'s what \`skills.defaults\` and \`skills.config.<name>\` are for.\n\n(Note: \`agent.yaml\`, the manifest for TypeScript portable agents, is a separate surface with its own rules and is out of scope for this guidance — see \`vibe-agent-toolkit:vat-agent-authoring\`.)\n\n## \`package.json\` Wiring\n\nFor projects that publish skills via npm, three fields tie VAT into the npm lifecycle:\n\n\`\`\`json\n{\n  \"name\": \"@myorg/my-skills\",\n  \"dependencies\": {\n    \"vibe-agent-toolkit\": \"latest\"\n  },\n  \"scripts\": {\n    \"build\": \"vat build\",\n    \"postinstall\": \"vat claude plugin install --npm-postinstall || exit 0\"\n  },\n  \"vat\": {\n    \"skills\": [\"my-skill-one\", \"my-skill-two\"]\n  }\n}\n\`\`\`\n\n- **\`dependencies.vibe-agent-toolkit\`** — runtime dep, not dev. Needed so the postinstall hook can find \`vat\`.\n- **\`scripts.postinstall\`** — registers the built plugin into the user\'s \`~/.claude/plugins/\` tree after \`npm install -g\` or any install that runs lifecycle scripts. The \`|| exit 0\` keeps \`npm install\` from aborting if the hook can\'t run (unusual but defensive).\n- **\`vat.skills\`** — declares which skill names this package ships. \`vat verify\` cross-checks this list against \`skills.include\` in \`vibe-agent-toolkit.config.yaml\`; mismatches fire \`PACKAGE_JSON_LISTS_UNKNOWN_SKILL\` / \`PACKAGE_JSON_MISSING_SKILL\`. The list is a packaging contract with npm, not a build input — \`vat build\` discovers skills from the config globs.\n\nThe full distribution pipeline (build, verify, npm publish, marketplace layout, managed settings) lives in \`vibe-agent-toolkit:vat-skill-distribution\`.\n\n## vibe-validate Integration\n\nIf the project uses vibe-validate (recommended), wire VAT into the validation config:\n\n\`\`\`yaml\n# vibe-validate.config.yaml (or relevant section)\nphases:\n  - name: vat-build-and-verify\n    parallel: false\n    commands:\n      - name: vat build\n        run: vat build\n      - name: vat verify\n        run: vat verify\n\`\`\`\n\n\`vat verify\` runs the full artifact check (resources → skills → marketplace → consistency); it\'s the authoritative gate before \`npm publish\`. In this repo\'s own config, \`bun run validate\` already does this — adopters typically mirror the pattern.\n\n## First-Time Setup Checklist\n\n1. \`npm install -g vibe-agent-toolkit\` (or add to local deps)\n2. \`vat --help\` — confirm the CLI resolves\n3. Create \`vibe-agent-toolkit.config.yaml\` with the minimal \`version: 1\` plus the sections you need\n4. Add \`resources/skills/SKILL.md\` or a kebab-case SKILL.md file and stage it in git (the skill discovery crawler uses \`git ls-files\` by default — untracked new files are skipped)\n5. \`vat skills validate\` — report any issues before building\n6. \`vat build\` — produces \`dist/\` artifacts\n7. \`vat verify\` — full consistency check; should be a no-op when clean\n8. If publishing: add the \`vat.skills\`, \`scripts.postinstall\`, and \`dependencies.vibe-agent-toolkit\` entries in \`package.json\` before \`npm publish\`\n\n## When Things Are Off\n\n- **\"No skills section in config yaml\"** — either the file isn\'t at the project root, or \`skills.include\` is missing.\n- **\"Found 0 skills\"** — glob doesn\'t match any SKILL.md files. Confirm the path and that the files are tracked by git (VAT\'s discovery respects \`.gitignore\` and \`git ls-files\`).\n- **\`PACKAGE_JSON_LISTS_UNKNOWN_SKILL\`** — \`vat.skills\` mentions a name not produced by \`skills.include\` discovery. Either add the file or remove the name.\n- **\`vat audit\` fires unexpected warnings** — load \`vibe-agent-toolkit:vat-audit\` for the full audit surface, including \`--compat\` and \`--exclude\` flags.\n\n## References\n\n- \`vibe-agent-toolkit:vat-skill-authoring\` — SKILL.md frontmatter, body structure, references, packagingOptions\n- \`vibe-agent-toolkit:vat-agent-authoring\` — TypeScript agent archetypes and runtime adapters\n- \`vibe-agent-toolkit:vat-skill-distribution\` — \`vat build\` / \`vat verify\` / marketplace / npm publish\n- \`vibe-agent-toolkit:vat-knowledge-resources\` — \`resources:\` collections and frontmatter schemas\n- \`vibe-agent-toolkit:vat-rag\` — \`rag:\` stores, embedding providers, \`vat rag index/query\`\n- \`vibe-agent-toolkit:vat-audit\` — \`vat audit\` for plugins, marketplaces, and installed skills\n- \`vibe-agent-toolkit:vat-skill-review\` — pre-publication quality checklist\n- [Getting Started Guide](../../../../docs/getting-started.md) — full setup walkthrough\n";
+export const text = "\n# VAT Adoption and Configuration\n\nThis skill covers the top-level orientation for adopting VAT in a project: installing the CLI, the overall shape of \`vibe-agent-toolkit.config.yaml\`, repo structure conventions, vibe-validate integration, and how npm postinstall wires plugin registration. Per-section deep-dives live in the sibling skills listed below.\n\n## Installing VAT\n\nVAT ships as the \`vibe-agent-toolkit\` npm package with a \`vat\` CLI:\n\n\`\`\`bash\n# Global install (most common during development)\nnpm install -g vibe-agent-toolkit\n\n# Or run without installing\nnpx vibe-agent-toolkit <command>\nbunx vibe-agent-toolkit <command>\n\n# As a runtime dependency (recommended for published packages that ship skills)\nnpm install --save vibe-agent-toolkit\n\`\`\`\n\nOnce installed, \`vat --help\` lists the top-level command groups. \`vat <group> --help\` and \`vat <group> <cmd> --help --verbose\` cover the rest.\n\n## Recommended Repo Structure\n\n\`\`\`\nmy-skills-project/\n├── package.json                        # includes \"vat\" block (see below)\n├── vibe-agent-toolkit.config.yaml      # single source of truth for VAT\n├── resources/\n│   ├── skills/                         # SKILL.md sources\n│   │   ├── SKILL.md                    # router skill (optional, for multi-skill bundles)\n│   │   └── my-skill.md\n│   └── content/                        # non-skill markdown (RAG, collections)\n├── agents/                             # TypeScript portable agents (optional)\n│   └── my-agent/\n│       ├── agent.yaml\n│       └── src/\n├── schemas/                            # JSON Schemas for resource collections\n├── docs/                               # project documentation\n└── dist/                               # generated (gitignored): vat build output\n\`\`\`\n\nThree conventions are load-bearing:\n\n1. **\`vibe-agent-toolkit.config.yaml\` at the project root** — VAT commands pick up this file when run from the project root or a subdirectory.\n2. **SKILL.md files live under \`resources/skills/\`** — any path works, but this one is what \`vat build\` and \`vat audit\` expect by default.\n3. **\`dist/\` is the only write target** — everything VAT generates goes there, and it\'s gitignored.\n\n## \`vibe-agent-toolkit.config.yaml\` Shape\n\n\`\`\`yaml\nversion: 1\n\nskills:\n  include: [\"resources/skills/SKILL.md\", \"resources/skills/*.md\"]\n  defaults:\n    linkFollowDepth: 2\n    excludeNavigationFiles: true\n    targets: [\'claude-code\']\n  config:\n    my-skill:\n      linkFollowDepth: 1\n\nresources:\n  collections:\n    docs:\n      include: [\"docs/**/*.md\"]\n      validation:\n        frontmatterSchema: \"schemas/doc.schema.json\"\n        mode: permissive\n\nclaude:\n  marketplaces:\n    my-marketplace:\n      owner: { name: \"my-org\" }\n      publish:\n        changelog: CHANGELOG.md\n        readme: README.md\n      plugins:\n        - name: my-plugin\n          description: \"What this plugin does\"\n\nrag:\n  stores:\n    default:\n      db: .rag-db/\n      include: [\"docs/**/*.md\"]\n\`\`\`\n\nSections and the skills that own their details:\n\n| Section | Owning skill |\n|---|---|\n| Top-level structure, \`version\`, section orientation | this skill (\`vat-adoption-and-configuration\`) |\n| \`skills:\` (include, defaults, per-skill config, packagingOptions) | \`vibe-agent-toolkit:vat-skill-authoring\` |\n| \`resources:\` (collections, schemas, validation modes) | \`vibe-agent-toolkit:vat-knowledge-resources\` |\n| \`claude:\` (marketplaces, plugins, publish, owner) | \`vibe-agent-toolkit:vat-skill-distribution\` |\n| \`rag:\` (stores, embedding providers) | \`vibe-agent-toolkit:vat-rag\` |\n\nWhen adding to a section, load the owning skill rather than re-deriving the shape from this file.\n\n## Config lives at the VAT project root\n\nA VAT project is a directory that contains a \`vibe-agent-toolkit.config.yaml\`. That file is authoritative for the project: it defines \`resources\`, \`skills\`, \`claude\`, and (optionally) \`rag\`. Nothing outside the config contributes to its behavior — there is no ambient configuration, no inheritance from parent directories, and no merge with sibling configs.\n\nVAT commands (\`vat build\`, \`vat verify\`, \`vat skills validate\`, \`vat skills build\`) read the config at the directory they are invoked from. Run them from the project root or from a subdirectory, or pass \`--cwd <path>\` to point them at a specific project. If you run a lifecycle command from somewhere that has no config, it will not find one — there is no upward walk here.\n\n**Multiple \`vibe-agent-toolkit.config.yaml\` files in one git repository mean multiple distinct VAT projects.** Each project is independent: configs do not compose, do not merge, and do not inherit from one another. Running VAT from outside any project directory operates on a union of whatever projects it discovers, but each project\'s rules are applied only to its own skills — per-skill packaging overrides in \`project-a/vibe-agent-toolkit.config.yaml\` never affect skills under \`project-b/\`.\n\n\`vat audit\` is the one command that knowingly spans projects, and even there it does not compose: audit is a general-purpose read-only scan that you may point at any path, configured or not. When it encounters a SKILL.md inside a configured VAT project, it walks UP to that skill\'s nearest-ancestor \`vibe-agent-toolkit.config.yaml\` and applies **only** that skill\'s packaging rules (from its own project\'s \`skills.config.<name>\`) to the finding. This is display sanity, not federation — audit never merges config data across project boundaries.\n\nIn practice, prefer one \`vibe-agent-toolkit.config.yaml\` per git repository. Multiple configs in a single repo are reasonable only for:\n\n- Committed test harnesses or fixtures that define their own toy VAT projects (for VAT\'s own tests, or for an adopter\'s integration tests).\n- Genuinely unrelated projects that happen to share a monorepo and each ship their own skills.\n\nIf you are tempted to use nested configs to \"share\" or \"override\" settings across related skills, fold everything into one project-level config instead — that\'s what \`skills.defaults\` and \`skills.config.<name>\` are for.\n\n(Note: \`agent.yaml\`, the manifest for TypeScript portable agents, is a separate surface with its own rules and is out of scope for this guidance — see \`vibe-agent-toolkit:vat-agent-authoring\`.)\n\n## \`package.json\` Wiring\n\nFor projects that publish skills via npm, three fields tie VAT into the npm lifecycle:\n\n\`\`\`json\n{\n  \"name\": \"@myorg/my-skills\",\n  \"dependencies\": {\n    \"vibe-agent-toolkit\": \"latest\"\n  },\n  \"scripts\": {\n    \"build\": \"vat build\",\n    \"postinstall\": \"vat claude plugin install --npm-postinstall || exit 0\"\n  },\n  \"vat\": {\n    \"skills\": [\"my-skill-one\", \"my-skill-two\"]\n  }\n}\n\`\`\`\n\n- **\`dependencies.vibe-agent-toolkit\`** — runtime dep, not dev. Needed so the postinstall hook can find \`vat\`.\n- **\`scripts.postinstall\`** — registers the built plugin into the user\'s \`~/.claude/plugins/\` tree after \`npm install -g\` or any install that runs lifecycle scripts. The \`|| exit 0\` keeps \`npm install\` from aborting if the hook can\'t run (unusual but defensive).\n- **\`vat.skills\`** — declares which skill names this package ships. \`vat verify\` cross-checks this list against \`skills.include\` in \`vibe-agent-toolkit.config.yaml\`; mismatches fire \`PACKAGE_JSON_LISTS_UNKNOWN_SKILL\` / \`PACKAGE_JSON_MISSING_SKILL\`. The list is a packaging contract with npm, not a build input — \`vat build\` discovers skills from the config globs.\n\nThe full distribution pipeline (build, verify, npm publish, marketplace layout, managed settings) lives in \`vibe-agent-toolkit:vat-skill-distribution\`.\n\n## vibe-validate Integration\n\nIf the project uses vibe-validate (recommended), wire VAT into the validation config:\n\n\`\`\`yaml\n# vibe-validate.config.yaml (or relevant section)\nphases:\n  - name: vat-build-and-verify\n    parallel: false\n    commands:\n      - name: vat build\n        run: vat build\n      - name: vat verify\n        run: vat verify\n\`\`\`\n\n\`vat verify\` runs the full artifact check (resources → skills → marketplace → consistency); it\'s the authoritative gate before \`npm publish\`. In this repo\'s own config, \`bun run validate\` already does this — adopters typically mirror the pattern.\n\n## First-Time Setup Checklist\n\n1. \`npm install -g vibe-agent-toolkit\` (or add to local deps)\n2. \`vat --help\` — confirm the CLI resolves\n3. Create \`vibe-agent-toolkit.config.yaml\` with the minimal \`version: 1\` plus the sections you need\n4. Add \`resources/skills/SKILL.md\` or a kebab-case SKILL.md file and stage it in git (the skill discovery crawler uses \`git ls-files\` by default — untracked new files are skipped)\n5. \`vat skills validate\` — report any issues before building\n6. \`vat build\` — produces \`dist/\` artifacts\n7. \`vat verify\` — full consistency check; should be a no-op when clean\n8. If publishing: add the \`vat.skills\`, \`scripts.postinstall\`, and \`dependencies.vibe-agent-toolkit\` entries in \`package.json\` before \`npm publish\`\n\n## When Things Are Off\n\n- **\"No skills section in config yaml\"** — either the file isn\'t at the project root, or \`skills.include\` is missing.\n- **\"Found 0 skills\"** — glob doesn\'t match any SKILL.md files. Confirm the path and that the files are tracked by git (VAT\'s discovery respects \`.gitignore\` and \`git ls-files\`).\n- **\`PACKAGE_JSON_LISTS_UNKNOWN_SKILL\`** — \`vat.skills\` mentions a name not produced by \`skills.include\` discovery. Either add the file or remove the name.\n- **\`vat audit\` fires unexpected warnings** — load \`vibe-agent-toolkit:vat-audit\` for the full audit surface, including \`--compat\` and \`--exclude\` flags.\n\n## References\n\n- \`vibe-agent-toolkit:vat-skill-authoring\` — SKILL.md frontmatter, body structure, references, packagingOptions\n- \`vibe-agent-toolkit:vat-agent-authoring\` — TypeScript agent archetypes and runtime adapters\n- \`vibe-agent-toolkit:vat-skill-distribution\` — \`vat build\` / \`vat verify\` / marketplace / npm publish\n- \`vibe-agent-toolkit:vat-knowledge-resources\` — \`resources:\` collections and frontmatter schemas\n- \`vibe-agent-toolkit:vat-rag\` — \`rag:\` stores, embedding providers, \`vat rag index/query\`\n- \`vibe-agent-toolkit:vat-audit\` — \`vat audit\` for plugins, marketplaces, and installed skills\n- \`vibe-agent-toolkit:vat-skill-review\` — pre-publication quality checklist\n- [Getting Started Guide](../../../../docs/getting-started.md) — full setup walkthrough\n";
 
 export const fragments = {
   installingVat: {
@@ -22,8 +22,8 @@ export const fragments = {
   },
   vibeAgentToolkitconfigyamlShape: {
     header: "## \`vibe-agent-toolkit.config.yaml\` Shape",
-    body: "\`\`\`yaml\nversion: 1\n\nskills:\n  include: [\"resources/skills/SKILL.md\", \"resources/skills/*.md\"]\n  defaults:\n    linkFollowDepth: 2\n    excludeNavigationFiles: true\n    targets: [\'claude-code\']\n  config:\n    my-skill:\n      linkFollowDepth: 1\n\nresources:\n  collections:\n    docs:\n      include: [\"docs/**/*.md\"]\n      validation:\n        frontmatterSchema: \"schemas/doc.schema.json\"\n        mode: permissive\n\nclaude:\n  marketplaces:\n    my-marketplace:\n      owner: { name: \"my-org\" }\n      publish:\n        changelog: CHANGELOG.md\n        readme: README.md\n      plugins:\n        - name: my-plugin\n          description: \"What this plugin does\"\n          skills: \"*\"\n\nrag:\n  stores:\n    default:\n      db: .rag-db/\n      include: [\"docs/**/*.md\"]\n\`\`\`\n\nSections and the skills that own their details:\n\n| Section | Owning skill |\n|---|---|\n| Top-level structure, \`version\`, section orientation | this skill (\`vat-adoption-and-configuration\`) |\n| \`skills:\` (include, defaults, per-skill config, packagingOptions) | \`vibe-agent-toolkit:vat-skill-authoring\` |\n| \`resources:\` (collections, schemas, validation modes) | \`vibe-agent-toolkit:vat-knowledge-resources\` |\n| \`claude:\` (marketplaces, plugins, publish, owner) | \`vibe-agent-toolkit:vat-skill-distribution\` |\n| \`rag:\` (stores, embedding providers) | \`vibe-agent-toolkit:vat-rag\` |\n\nWhen adding to a section, load the owning skill rather than re-deriving the shape from this file.",
-    text: "## \`vibe-agent-toolkit.config.yaml\` Shape\n\n\`\`\`yaml\nversion: 1\n\nskills:\n  include: [\"resources/skills/SKILL.md\", \"resources/skills/*.md\"]\n  defaults:\n    linkFollowDepth: 2\n    excludeNavigationFiles: true\n    targets: [\'claude-code\']\n  config:\n    my-skill:\n      linkFollowDepth: 1\n\nresources:\n  collections:\n    docs:\n      include: [\"docs/**/*.md\"]\n      validation:\n        frontmatterSchema: \"schemas/doc.schema.json\"\n        mode: permissive\n\nclaude:\n  marketplaces:\n    my-marketplace:\n      owner: { name: \"my-org\" }\n      publish:\n        changelog: CHANGELOG.md\n        readme: README.md\n      plugins:\n        - name: my-plugin\n          description: \"What this plugin does\"\n          skills: \"*\"\n\nrag:\n  stores:\n    default:\n      db: .rag-db/\n      include: [\"docs/**/*.md\"]\n\`\`\`\n\nSections and the skills that own their details:\n\n| Section | Owning skill |\n|---|---|\n| Top-level structure, \`version\`, section orientation | this skill (\`vat-adoption-and-configuration\`) |\n| \`skills:\` (include, defaults, per-skill config, packagingOptions) | \`vibe-agent-toolkit:vat-skill-authoring\` |\n| \`resources:\` (collections, schemas, validation modes) | \`vibe-agent-toolkit:vat-knowledge-resources\` |\n| \`claude:\` (marketplaces, plugins, publish, owner) | \`vibe-agent-toolkit:vat-skill-distribution\` |\n| \`rag:\` (stores, embedding providers) | \`vibe-agent-toolkit:vat-rag\` |\n\nWhen adding to a section, load the owning skill rather than re-deriving the shape from this file."
+    body: "\`\`\`yaml\nversion: 1\n\nskills:\n  include: [\"resources/skills/SKILL.md\", \"resources/skills/*.md\"]\n  defaults:\n    linkFollowDepth: 2\n    excludeNavigationFiles: true\n    targets: [\'claude-code\']\n  config:\n    my-skill:\n      linkFollowDepth: 1\n\nresources:\n  collections:\n    docs:\n      include: [\"docs/**/*.md\"]\n      validation:\n        frontmatterSchema: \"schemas/doc.schema.json\"\n        mode: permissive\n\nclaude:\n  marketplaces:\n    my-marketplace:\n      owner: { name: \"my-org\" }\n      publish:\n        changelog: CHANGELOG.md\n        readme: README.md\n      plugins:\n        - name: my-plugin\n          description: \"What this plugin does\"\n\nrag:\n  stores:\n    default:\n      db: .rag-db/\n      include: [\"docs/**/*.md\"]\n\`\`\`\n\nSections and the skills that own their details:\n\n| Section | Owning skill |\n|---|---|\n| Top-level structure, \`version\`, section orientation | this skill (\`vat-adoption-and-configuration\`) |\n| \`skills:\` (include, defaults, per-skill config, packagingOptions) | \`vibe-agent-toolkit:vat-skill-authoring\` |\n| \`resources:\` (collections, schemas, validation modes) | \`vibe-agent-toolkit:vat-knowledge-resources\` |\n| \`claude:\` (marketplaces, plugins, publish, owner) | \`vibe-agent-toolkit:vat-skill-distribution\` |\n| \`rag:\` (stores, embedding providers) | \`vibe-agent-toolkit:vat-rag\` |\n\nWhen adding to a section, load the owning skill rather than re-deriving the shape from this file.",
+    text: "## \`vibe-agent-toolkit.config.yaml\` Shape\n\n\`\`\`yaml\nversion: 1\n\nskills:\n  include: [\"resources/skills/SKILL.md\", \"resources/skills/*.md\"]\n  defaults:\n    linkFollowDepth: 2\n    excludeNavigationFiles: true\n    targets: [\'claude-code\']\n  config:\n    my-skill:\n      linkFollowDepth: 1\n\nresources:\n  collections:\n    docs:\n      include: [\"docs/**/*.md\"]\n      validation:\n        frontmatterSchema: \"schemas/doc.schema.json\"\n        mode: permissive\n\nclaude:\n  marketplaces:\n    my-marketplace:\n      owner: { name: \"my-org\" }\n      publish:\n        changelog: CHANGELOG.md\n        readme: README.md\n      plugins:\n        - name: my-plugin\n          description: \"What this plugin does\"\n\nrag:\n  stores:\n    default:\n      db: .rag-db/\n      include: [\"docs/**/*.md\"]\n\`\`\`\n\nSections and the skills that own their details:\n\n| Section | Owning skill |\n|---|---|\n| Top-level structure, \`version\`, section orientation | this skill (\`vat-adoption-and-configuration\`) |\n| \`skills:\` (include, defaults, per-skill config, packagingOptions) | \`vibe-agent-toolkit:vat-skill-authoring\` |\n| \`resources:\` (collections, schemas, validation modes) | \`vibe-agent-toolkit:vat-knowledge-resources\` |\n| \`claude:\` (marketplaces, plugins, publish, owner) | \`vibe-agent-toolkit:vat-skill-distribution\` |\n| \`rag:\` (stores, embedding providers) | \`vibe-agent-toolkit:vat-rag\` |\n\nWhen adding to a section, load the owning skill rather than re-deriving the shape from this file."
   },
   configLivesAtTheVatProjectRoot: {
     header: "## Config lives at the VAT project root",

package/dist/generated/resources/skills/vat-skill-distribution.d.ts

@@ -31,6 +31,7 @@ export const fragments: {
   readonly quickReference: Fragment;
   readonly runningVatWithoutGlobalInstall: Fragment;
   readonly futureZeroDependencyPostinstallOptionB: Fragment;
+  readonly fullPluginAuthoringCommandsHooksAgentsMcp: Fragment;
 };
 
 export type FragmentName = keyof typeof fragments;