Git-tracked source for Claude Code skills that are useful across many projects (not specific to one repo). Each skill is a directory containing a SKILL.md plus any bundled assets (scripts, templates).
Claude Code loads skills from ~/.claude/skills/<name>/. That deployed location is not git-tracked. So each cross-project skill has two copies:
| Copy | Path | Edit here? | Git-tracked? |
|---|---|---|---|
| Source | _skills/<name>/ (this dir) |
YES — all changes here | Yes (MetaProject) |
| Deployed | ~/.claude/skills/<name>/ |
NO — never edit directly | No |
After editing a skill's source, copy the whole directory to the deployed path:
cp -r ~/Code/_claude.MetaProject/_skills/<name>/. ~/.claude/skills/<name>/Then restart / reload the Claude session so the updated skill is picked up.
research-pdf— generate a polished, tablet-ready PDF compendium from a set of Markdown research docs (branded cover + auto TOC + styled sections, with inline MermaidJS diagrams rendered to SVG offline via a vendoredvendor/mermaid.min.js), via python-markdown + custom CSS rendered by Chrome headless. Invoke with/research-pdfor let it trigger on a PDF-export request.
This source→deploy cp is itself a small manual migration step — the same class of problem tracked in _backlog_TODOs/LATER-001 (how workflow/skill revisions propagate consistently across 20+ projects). A globally-deployed skill sidesteps per-repo copying entirely (one deploy serves every project), but the source→deploy hop still wants a process. Until that's formalized, the rule is simply: edit source here, redeploy with the cp above, don't edit the deployed copy.