---
name: recursive-spine-pollinate
description: Use when something just proved itself in real work and should be carried to other projects — captures it as a pollen record in the builder's hive (registry file + paired issue), or, in pull mode, reads every configured hive and offers relevant transplants into the current repo, recording each transplant back onto the record. Interview-driven hive config; never ships a default hive; routes private-proof pollen to a private hive only.
---

# recursive-spine: pollinate

Two modes. **Capture** files a proven element into a hive; **pull** brings
hive pollen into the current work. Ask which the user wants if the
invocation doesn't say. Read `${CLAUDE_PLUGIN_ROOT}/pollen/README.md` for
the record schema before writing any record.

## Hive configuration (both modes, first)

Read the invoking repo's dialect note (`docs/tracking-dialect.md` or
equivalent) for a `pollinate:` section listing hive repos and each hive's
visibility. If absent, interview — never assume:

1. "Which repo is your hive (where pollen records live)?" Accept several;
   record each as `owner/repo (public|private)`.
2. If the builder works across public and private projects, recommend one
   hive per visibility scope (the two-hive model): private-proof pollen
   must never enter a hive whose readers can't see its source.
3. Write the answers to the dialect note before proceeding. No default
   hive ships with this skill — the hive is the builder's own answer.

Degraded modes, always loud: no `gh` auth or not in a repo → draft the
record locally, print it, and tell the builder exactly what to file where.
Hive unreachable → report the error and stop; never guess.

## Capture mode

1. **Interview (brief — target under a minute):**
   - What worked? (one sentence)
   - What form is it? `snippet` / `pattern` / `skill-candidate` / `config`
   - Where's the proof? (repo + issue/PR — the `source:` field; the proof
     must exist, per the no-invented-pollen doctrine)
2. **Route by proof visibility:** `gh repo view <source-repo> --json
   visibility`. Private proof → a private hive; public proof → the public
   hive. If no hive of the required visibility is configured, say so and
   offer to add one to the dialect note. If the dialect note's pollinate
   section records an explicit routing rule, that recorded rule takes
   precedence over the raw visibility flag.
3. **Dedup check:** a raw fetch (or clone) and read of the target hive's
   `pollen/` directory is the primary, deterministic registry check; use
   `gh search issues -R <hive> --label pollen --search <keywords>` to
   also check `pollen`-labeled issues for the same ground. Near match →
   offer "record a transplant on the existing pollen" instead of filing
   a twin.
4. **File the record:** branch + PR to the hive adding
   `pollen/<slug>.md` per the schema (stage `seedling`, `transplants: []`),
   plus artifact files under `pollen/<slug>/` when the pollen is a file.
   Then file the paired issue in the hive: label `pollen`, title
   `pollen: <slug> — <one-line what-worked>`, body linking the record file
   and the proof. Public hive rule: every reference in record and issue
   must resolve for every reader — if a link would point at a repo the
   hive's readers can't see, the pollen belongs in a private hive (or the
   reference must be abstracted).
5. **Report:** record path, issue URL, stage, and anything skipped and why.

## Pull mode

1. Read `pollen/` from **every** configured hive (clone or raw fetch).
2. Match records against the current work context (the repo's language,
   the task at hand, labels in play). Offer only genuine fits with a
   one-line "why this applies here". Nothing relevant → say so and stop;
   no forced suggestions.
3. On acceptance, perform the transplant: copy and adapt the artifact, or
   apply the pattern. Show the diff before writing.
4. Record the transplant, both halves:
   - append the target repo to the record's `transplants:` list (PR to
     the hive; flip `stage:` to `transplanted` if it was `seedling`);
   - comment on the paired pollen issue: which repo, what was adapted,
     link to the receiving commit/PR.
5. If a record now has ≥2 transplants, note it is graduation-eligible and
   name the kin repo that owns the concern — but graduation is the
   builder's deliberate act, never automatic.

## Declassification (deliberate, never automatic)

To publish a private-hive pollen: re-file it into the public hive with
scrubbed provenance ("proven in a private production app" — no name, no
link), a fresh paired issue, and a note in the private record pointing to
its public sibling. Offer this only when the builder asks.

## What this skill never does

No transplants without approval, no auto-graduation, no default hive, no
private references in a public hive. Pushing "consider adopting X" issues
into target repos is deliberately out of scope: deferred as
recursive-spine#38.