| name | source-provenance |
| description | Track provenance for imported skills, agents, hooks, prompts, plugins, scripts, and third-party workflow assets. |
Source Provenance
Before adding or modifying imported agent assets, record where they came from.
Workflow
Resolve the checkout explicitly; never assume the caller's cwd:
DOTFILES_DIR="${DOTFILES_DIR:-$HOME/work/dotfiles}"
test -f "$DOTFILES_DIR/scripts/source_provenance_audit.py"
- For a new external asset, capture upstream URL, license, and whether this repo is vendoring, adapting, or only inspired by it.
- Run
python3 "$DOTFILES_DIR/scripts/source_provenance_audit.py" to find local assets that likely need provenance notes.
- Prefer a short comment/frontmatter note near the adapted file over a separate top-level document.
- If provenance is unknown, mark it as unknown and flag it as a risk instead of inventing attribution.
For Agent Skills, prefer the standard frontmatter fields license, compatibility,
and string-valued metadata. Store repo-specific provenance under namespaced keys:
license: MIT
compatibility: "Requires public network access and gh."
metadata:
dotfiles.provenance.upstream: https://github.com/example/project
dotfiles.provenance.mode: adapted
dotfiles.provenance.local-changes: "Added local safety and install boundaries."
Keep a legacy near-file provenance sentence only when the asset format cannot carry
frontmatter. Validate strict audit results with:
python3 "$DOTFILES_DIR/scripts/source_provenance_audit.py" --strict
Required fields for adapted assets
- Upstream: URL or package/repo identity
- License: SPDX id or explicit unknown
- Mode: vendored, adapted, inspired-by, or original
- Local changes: one short sentence when adapted