Skill Import Provenance
Keep Jovani-owned work and primary authorities separate from external rejection evidence. Read provenance record before proposing an owned-source transfer.
Workflow
- Resolve the exact owned source, revision, artifact, author, license, destination, and authority for the proposed transfer.
- If the source is a third-party skill catalog, stop. Do not track, cite, mirror, adapt, vendor, or use it as an implementation source. Any authorized investigation stays outside Git and can influence rejection boundaries only.
- Confirm that Jovani owns or has separately documented authority for every transferred file and that the license permits the destination use.
- Inventory the exact files proposed for transfer and their dependencies, scripts, assets, hooks, and network behavior.
- Run or obtain a security review appropriate to the package's influence and execution surface.
- Choose one capability disposition used throughout the catalog:
covered: an accepted public capability already satisfies the needpartial: existing public coverage leaves a named gappublic_candidate: the capability is reusable and can be independently supportedprivate_overlay: correct use depends on private context or authorityrejected: the capability is unsafe, unsupported, obsolete, duplicative, or not permitted
- For current catalog work, use
original or an honestly preserved historical clean-room method. Do not introduce new adapted, vendored, or third-party reference-only implementations.
- Record provenance before materializing the transfer using the exact schema field names, including
pinned_revision, reviewed_on, and reviewed_material.
- Apply the smallest authorized change. Preserve required notices and avoid unrelated updates.
- Validate the result in every supported host and record rereview triggers, update policy, and revocation path.
Stop conditions
Stop on any third-party skill-catalog source, unclear ownership, incompatible or absent licensing, unverifiable artifact origin, unexplained binary content, unsafe activation, or a review scope that cannot cover the proposed package. Do not install or materialize a rejected source.
1---2name: skill-import-provenance3description: Review provenance before transferring Jovani-owned skill material between authorized repositories or distributions. Invoke explicitly for an owned-source transfer or a decision about whether proposed external skill material must be rejected; third-party skill catalogs are never implementation sources.4license: MIT5---67# Skill Import Provenance89Keep Jovani-owned work and primary authorities separate from external rejection evidence. Read [provenance record](references/provenance-record.md) before proposing an owned-source transfer.1011## Workflow12131. Resolve the exact owned source, revision, artifact, author, license, destination, and authority for the proposed transfer.142. If the source is a third-party skill catalog, stop. Do not track, cite, mirror, adapt, vendor, or use it as an implementation source. Any authorized investigation stays outside Git and can influence rejection boundaries only.153. Confirm that Jovani owns or has separately documented authority for every transferred file and that the license permits the destination use.164. Inventory the exact files proposed for transfer and their dependencies, scripts, assets, hooks, and network behavior.175. Run or obtain a security review appropriate to the package's influence and execution surface.186. Choose one capability disposition used throughout the catalog:19 - `covered`: an accepted public capability already satisfies the need20 - `partial`: existing public coverage leaves a named gap21 - `public_candidate`: the capability is reusable and can be independently supported22 - `private_overlay`: correct use depends on private context or authority23 - `rejected`: the capability is unsafe, unsupported, obsolete, duplicative, or not permitted247. For current catalog work, use `original` or an honestly preserved historical `clean-room` method. Do not introduce new `adapted`, `vendored`, or third-party `reference-only` implementations.258. Record provenance before materializing the transfer using the exact schema field names, including `pinned_revision`, `reviewed_on`, and `reviewed_material`.269. Apply the smallest authorized change. Preserve required notices and avoid unrelated updates.2710. Validate the result in every supported host and record rereview triggers, update policy, and revocation path.2829## Stop conditions3031Stop on any third-party skill-catalog source, unclear ownership, incompatible or absent licensing, unverifiable artifact origin, unexplained binary content, unsafe activation, or a review scope that cannot cover the proposed package. Do not install or materialize a rejected source.
JovaniPink