docs: catalogs track main by design, drop tag-pinning narrative (#176)

## Summary
We decided not to pin the marketplace catalogs to release tags. The docs
still described tag-pinning as a planned "mechanical follow-up", which
is now misleading. This updates the text to say the catalogs track
`main` by design.

## Changes
- `CLAUDE.md`, `CONTRIBUTING.md`, `README.md`, `metaplugin/README.md`:
drop the "follow-up flips to tag-pinning" language; state the catalogs
track `main`.
- `metaplugin/plugin.meta.json`: update the `//source` comment to match.

No behavior change: `ref_template` stays `main` and every catalog keeps
`ref: main`.

## Test plan
- [x] `python3 scripts/skills.py validate` (clean, no drift from the
`//source` comment edit)
- [x] `grep` confirms no tag-pinning narrative remains outside the
generated bundle

Signed-off-by: simon <simon.faltum@databricks.com>

Author: simonfaltum

CLAUDE.md

@@ -59,8 +59,8 @@ and `assets/` (Codex's interface logo). At the repo root, four `marketplace.json
 catalogs (`.claude-plugin/`, `.github/plugin/`, `.agents/plugins/`,
 `.cursor-plugin/` — Cursor's is new) each point a **scoped source** at *its own*
 provider subfolder (`plugins/databricks/<provider>`), so an install fetches only
-that provider's payload. The catalogs currently track `main`; a mechanical
-follow-up flips them to tag-pinning. The bundles, the catalogs, every
+that provider's payload. The catalogs track `main`, where the committed bundle
+lives. The bundles, the catalogs, every
 `plugin.json`, the hook wiring, the routing files, the rendered commands, and
 `manifest.json` are all **generated** from
 [`metaplugin/plugin.meta.json`](./metaplugin/plugin.meta.json) (and the templated
@@ -74,12 +74,10 @@ the `skills` map (with a `keyword`).
 
 Everything under `plugins/` is generated, committed, and drift-checked (it is not
 gitignored in this repo). The catalogs' scoped source is configured under
-`marketplace.source` in `metaplugin/plugin.meta.json`; today every catalog tracks
-`main` (`ref: main`), where the committed bundle lives, so the change is safe to
-land with no release. A mechanical follow-up flips `ref_template` to `v{version}`
-so the ref-capable tools (Claude, Codex, Copilot) serve frozen release tags
-instead of main HEAD; Cursor cannot pin a ref and always tracks the default
-branch. The CLI's raw-skills (files-channel) installer is unaffected — it keeps
+`marketplace.source` in `metaplugin/plugin.meta.json`; every catalog tracks
+`main` (`ref: main`), where the committed bundle lives, so installs follow the
+latest committed bundle. The catalogs are not pinned to release tags by design.
+The CLI's raw-skills (files-channel) installer is unaffected — it keeps
 fetching the root `skills/`, so the manifest's stable `repo_dir` stays `skills`.
 
 The generator itself lives in `scripts/skillsgen/` (a package split by concern:

CONTRIBUTING.md

@@ -66,8 +66,7 @@ display names, the scoped-source config (`marketplace.source`), and
 hook/command/rule wiring, lives once in **`metaplugin/plugin.meta.json`**.
 `scripts/skills.py generate` renders it into a **per-provider** bundle under
 `plugins/databricks/<provider>/` and the four root catalogs, each pointing a
-scoped source at *its own* provider subfolder (currently `ref: main`; a follow-up
-flips it to tag-pinning):
+scoped source at *its own* provider subfolder (`ref: main`):
 
 - per-provider bundles (each self-contained, only what that provider uses):
   - `plugins/databricks/claude/`   — `.claude-plugin/plugin.json` + `skills/` + `commands/` + `hooks/`
@@ -196,11 +195,9 @@ through a PR and the merge queue.
   marketplace keys updates on the `version` field, so a release that ships
   without bumping it leaves marketplace clients on the cached copy and they never
   see the new skills.
-- The catalogs currently track `main` (`ref: main`), so the bundle they serve is
-  whatever is committed on `main`; bumping the version does not change which ref
-  installs follow. A planned follow-up flips `marketplace.source.ref_template` to
-  `v{version}` so the ref-capable catalogs re-stamp to each release tag (the tag
-  contains the `plugins/databricks/` bundle, since it is committed on `main`).
+- The catalogs track `main` (`ref: main`), so the bundle they serve is whatever
+  is committed on `main`; bumping the version does not change which ref installs
+  follow. The catalogs are not pinned to release tags by design.
 - **If a release half-completes** (the tag was pushed but the GitHub release was
   not created, for example the job died between the two steps), the guard treats
   the version as already published and skips it on the next run. Recover by

README.md

@@ -244,8 +244,7 @@ The manifest is consumed by the CLI to discover available skills.
 The repo ships one plugin to four targets (Claude Code, Codex, Copilot, Cursor).
 Every agent fetches the built `plugins/databricks/` bundle (a generated copy of
 the source plus the four per-target `plugin.json`); four `marketplace.json`
-catalogs at the repo root each point a scoped source at it (currently tracking
-`main`; tag-pinning to frozen releases is a mechanical follow-up). The
+catalogs at the repo root each point a scoped source at it (tracking `main`). The
 bundle, the catalogs, the four `plugin.json`, and `manifest.json` are all
 **generated** from a single source of truth,
 [`metaplugin/plugin.meta.json`](./metaplugin/plugin.meta.json), by `scripts/skills.py`. Do not

metaplugin/README.md

@@ -24,9 +24,8 @@ are reverted:
 - **Marketplace catalogs** (at the repo root): `.claude-plugin/marketplace.json`,
   `.github/plugin/marketplace.json`, `.agents/plugins/marketplace.json`,
   `.cursor-plugin/marketplace.json` (Cursor's is new). Each points a scoped source
-  at *its own* provider subfolder, e.g. `plugins/databricks/claude` (currently
-  `ref: main`; a mechanical follow-up flips it to tag-pinning), configured under
-  `plugin.meta.json` `marketplace.source`.
+  at *its own* provider subfolder, e.g. `plugins/databricks/claude` (`ref: main`),
+  configured under `plugin.meta.json` `marketplace.source`.
 - **Hook wiring**: `hooks/hooks.json`, `hooks/codex-hooks.json`,
   `hooks/copilot-hooks.json`, `hooks/cursor-hooks.json` (per-dialect, at the root
   so generation doesn't collide). The bundle renames each into its provider

metaplugin/plugin.meta.json

@@ -20,7 +20,7 @@
     "description": "Databricks agent skills for AI coding assistants.",
     "owner": { "name": "Databricks" },
     "displayName": "Databricks Agent Skills",
-    "//source": "How each catalog points at the built bundle. The four plugin.json live under <subdir>/<target-dir>/, so agents fetch only <subdir> (a scoped/sparse clone). ref_template is the git ref each ref-capable catalog (Claude/Codex/Copilot) pins. It currently tracks `main`, where the bundle is committed, so this change is safe to land standalone with no release. A mechanical follow-up flips ref_template to `v{version}` so installs serve frozen release tags instead of main HEAD (the proposal's goal); `{version}` is filled from `version` above. Cursor cannot pin a ref, so it omits one and also tracks the default branch. NOTE: the Codex entry still needs its `policy` block + a remote git-subdir-at-a-tag smoke test (open question in the proposal); add `codex_policy` here once verified.",
+    "//source": "How each catalog points at the built bundle. The four plugin.json live under <subdir>/<target-dir>/, so agents fetch only <subdir> (a scoped/sparse clone). ref_template is the git ref the ref-capable catalogs (Claude/Codex/Copilot) use; it is `main`, where the committed bundle lives, so installs follow the latest committed bundle. The catalogs are not pinned to release tags by design. Cursor cannot pin a ref anyway and tracks the default branch. NOTE: the Codex entry still needs its `policy` block + a remote git-subdir-at-a-tag smoke test (open question in the proposal); add `codex_policy` here once verified.",
     "source": {
       "subdir": "plugins/databricks",
       "repo": "databricks/databricks-agent-skills",