How do I install the Vendoring Skills skill?

Run npx skillmds@latest add ghostlygawd/vendoring-skills in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

What does the Vendoring Skills skill do?

Vendoring a third-party skill It is listed under Coding & Dev Tools on SkillMD.

Is Vendoring Skills safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Vendoring Skills?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Vendoring Skills free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Vendoring Skills?

GhostlyGawd (@ghostlygawd) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Vendoring Skills by ghostlygawd — Agent Skill

Name: Vendoring Skills
Author: GhostlyGawd

File contents

Vendoring a third-party skill

Importing an external skill is NOT authoring a harness learning — it is adding a vendored dependency. Keep it traceable and lean.

Placement

Default to the shared trunk skills/ (kernel prime directive 6, ONE TRUNK): one brain, every account sees it via the config-dir symlink (on Windows that link must be a REAL symlink, not an MSYS ln -s copy, or the account forks the trunk — see ADR 0004). Raise account-local isolation only if the user needs real credential/scope separation — don't over-argue it when they said "to my account"; the trunk is the default.

Install — do NOT use `npx skills add` for trunk vendoring

npx skills add <repo> pulls the WHOLE repo and symlinks it into an agent skills dir — wrong for a slimmed, committed trunk artifact. Instead:

git clone --depth 1 <repo> into a gitignored scratch dir (e.g. under .claude-private/.../_staging); clean it up after.
Copy only the functional skill into skills/<name>/: SKILL.md + references/ + scripts/ + small functional assets (.jsx/.html/.js/.svg/.json).
DROP heavy / non-functional media: audio/BGM (.mp3), showcases/, sfx/, demos/, sample dirs. (huashu-design went 32 MB → 814 KB this way.) State plainly what you dropped.

Provenance & updates

Add a provenance: line to the vendored SKILL.md: upstream URL + commit sha + date. Updates = re-vendor (re-clone, re-slim), never hand-edit the body — or you lose the ability to track upstream.

When SKILL.md exceeds the B3 body cap (200 lines)

Do NOT gut the upstream file to fit. Add the skill PATH to the human-gated VENDORED_SKILLS allowlist (the B3 waiver) in lint/lint_harness.py — create it if it does not exist yet. That is an enforcement-layer edit, so go via /harness-pr (HUMAN_APPROVED marker → harness-auditor → /run-evals → human merge). The allowlist is path-gated; never a self-asserted frontmatter flag (see skill harness-authoring).

Flag the gaps, don't recite them

Bundled scripts usually need external runtime deps (node/ffmpeg/puppeteer/API keys) and the dropped media. Capture each as a follow-up (harness followup add); end with a count line, surface on pull (skill follow-up-handling).

---name: vendoring-skillsdescription: Vendoring a third-party skill---# Vendoring a third-party skillImporting an external skill is NOT authoring a harness learning — it is adding avendored dependency. Keep it traceable and lean.## PlacementDefault to the shared trunk `skills/` (kernel prime directive 6, ONE TRUNK): onebrain, every account sees it via the config-dir symlink (on Windows that linkmust be a REAL symlink, not an MSYS `ln -s` copy, or the account forks the trunk— see ADR 0004). Raise account-localisolation only if the user needs real credential/scope separation — don'tover-argue it when they said "to my account"; the trunk is the default.## Install — do NOT use `npx skills add` for trunk vendoring`npx skills add <repo>` pulls the WHOLE repo and symlinks it into an agent skillsdir — wrong for a slimmed, committed trunk artifact. Instead:1. `git clone --depth 1 <repo>` into a gitignored scratch dir (e.g. under `.claude-private/.../_staging`); clean it up after.2. Copy only the functional skill into `skills/<name>/`: `SKILL.md` + `references/` + `scripts/` + small functional assets (`.jsx/.html/.js/.svg/.json`).3. DROP heavy / non-functional media: audio/BGM (`.mp3`), `showcases/`, `sfx/`, `demos/`, sample dirs. (huashu-design went 32 MB → 814 KB this way.) State plainly what you dropped.## Provenance & updatesAdd a `provenance:` line to the vendored `SKILL.md`: upstream URL + commit sha +date. Updates = re-vendor (re-clone, re-slim), never hand-edit the body — or youlose the ability to track upstream.## When SKILL.md exceeds the B3 body cap (200 lines)Do NOT gut the upstream file to fit. Add the skill PATH to the human-gated `VENDORED_SKILLS`allowlist (the B3 waiver) in `lint/lint_harness.py` — create it if it does notexist yet. That is an enforcement-layer edit, so go via /harness-pr (HUMAN_APPROVEDmarker → harness-auditor → /run-evals → human merge). The allowlist is path-gated;never a self-asserted frontmatter flag (see skill harness-authoring).## Flag the gaps, don't recite themBundled scripts usually need external runtime deps (node/ffmpeg/puppeteer/APIkeys) and the dropped media. Capture each as a follow-up (`harness followup add`);end with a count line, surface on pull (skill follow-up-handling).

Frequently asked questions

Vendoring Skills