The skills that don't belong to any one project.
Skills managed with manage-skills live in whichever repo owns them — a Perl module keeps its Perl skill, a Kubernetes cluster repo keeps its cluster skill. This repo holds the rest: knowledge that applies across many projects and has no single home of its own.
The rule: a skill lives here only as long as nothing else claims it. The moment a skill belongs to one specific project, it moves there and this repo drops the link.
| Group | Skills | What it holds |
|---|---|---|
| authoring | 5 | Skills about skills — writing them, mining them out of existing code, compressing them, the library's own rules, and the agent team that consumes them |
| claude | 3 | Working with Claude itself — headless spawning, talking across running sessions, routing work across model tiers |
| codex | 2 | Working with the Codex CLI — non-interactive runs, and reaching threads that already exist |
| development | 1 | Engineering practice independent of language — debugging discipline |
| git | 2 | How repositories are used, and how commit messages are written |
| perl | 11 | House style, object systems including Mojo::Base, typing, async, MCP, XS and Alien, release tooling |
| social-media | 2 | LinkedIn and Twitch — platform mechanics, content practice, and the DACH legal duties that have no US equivalent |
| software | 1 | Project scaffolding across languages |
| system-and-network-administration | 8 | Machines, networks, containers, Kubernetes, admin automation |
Each group README describes every skill in it: what it covers, and when to load it.
| Skill | What it is |
|---|---|
| getty-agent-team | A whole multi-agent setup for a project: subagents, briefing-preloaded skills, karr wiring |
| getty-skill-library | Where a skill lives, what it is named, and how the hardlinks stay intact |
| skill-authoring | Writing a SKILL.md that fires from its description and then gets followed |
| skill-compressor | Shrinking or merging skills without losing the rules that drive behaviour |
| skill-mining | Deriving skill content from a codebase instead of inventing conventions |
| Skill | What it is |
|---|---|
| claude-cross-session | One Claude session starting, watching and messaging another |
| claude-headless | Driving Claude Code as a subprocess: -p, JSON, permissions, the multi-turn channel |
| model-routing | Choosing a model tier by the hardest dimension the work routinely hits |
| Skill | What it is |
|---|---|
| codex-cross-session | Reaching an existing Codex thread: the queue, the daemon, --remote |
| codex-headless | codex exec non-interactively: JSONL events, sandboxes, resuming a thread |
| Skill | What it is |
|---|---|
| feedback-loop-debugging | A six-phase discipline for hard bugs, built on a fast pass/fail signal |
| Skill | What it is |
|---|---|
| getty-git-commit-style | Imperative summary, one body line per change, and how changelog entries read |
| getty-git-usage | Linear history: rebase over merge, and --force-with-lease after it |
| Skill | What it is |
|---|---|
| getty-perl-core | The base layer: module loading, object-system choice, errors, subroutine shape |
| getty-perl-distribution | Creating a CPAN distribution, or bringing an existing one to house standard |
| getty-perl-moo | Moo classes and roles — roles for reuse, inheritance only for a stable is-a |
| getty-perl-moose | The same shape in Moose, plus make_immutable on every class |
| getty-perl-typing | Whether a project needs a type system at all, and which one is cheap here |
| perl-alien | Alien::Build: providing a C library or tool through CPAN |
| perl-io-async-future | PEVANS-style async Perl, and its unforgiving lifetime rules |
| perl-mcp | Building an MCP server in Perl with MCP::Server |
| perl-mojo | Mojo::Base as an object system, plus the Mojo::* toolkit around it |
| perl-release-dist-ini | Dist::Zilla for any distribution, independent of the author bundle |
| perl-xs | The Perl/C boundary, and why an .xs file is C behind a preprocessor |
| Skill | What it is |
|---|---|
| Formats, how distribution actually works, and the DACH legal duties | |
| twitch | Channel operation end to end: encoder, growth, chat, monetization, moderation |
| Skill | What it is |
|---|---|
| getty-create-software | Scaffolding a new project from the signals that reveal its type |
| Skill | What it is |
|---|---|
| docker | Docker and Compose as one workflow — the decisions and the traps |
| docker-engine-api | Speaking the Engine API over the socket instead of shelling out to docker |
| docker-registry | registry:2 as two products in one binary, and the pull-through trap |
| kubernetes-cilium-concepts | Cilium replacing CNI, kube-proxy, policy, encryption and ingress at once |
| kubernetes-concepts | Control plane, resource hierarchy, and how ownership and selectors tie it together |
| kubernetes-gpu | The four layers that must line up before a pod can use a GPU |
| kubernetes-rke2 | RKE2 and K3s as one topic, with the differences named where they exist |
| rex | Perl automation from a Rexfile, and the OpenSSH connection trap |
An owner name on its own is enough — it resolves to that owner's skills repo:
manage-skills sources add Getty # github.com/Getty/skills
manage-skills locations # see what's available
manage-skills link getty-perl-moo getty-git-usageWith a local checkout, register the checkout itself; the groups a level inside it are found on their own:
manage-skills sources add <checkout> Getty shared skillsThe same files also ship as a plugin for Claude Code (.claude-plugin/) and for
Codex (.codex-plugin/) — three distribution routes, one source of truth.
getty- prefixed skills prescribe — a house convention chosen over other valid
options, or the API of Getty's own software. Unprefixed skills are reference —
documentation of how a public tool or protocol behaves, equally true for anyone.
The full naming and placement rules are themselves a skill:
getty-skill-library.
Write it where it's used first. Only pull it in here once a second, unrelated project
needs the same knowledge — that's the signal it has outgrown a single home. The
workbench for that is the authoring group: skill-authoring
for the content, getty-skill-library for placement, naming, and the hardlink editing
discipline.
A skill has to be listed in four places — its group README, the group table and the
skill table above, and both plugin manifests. bin/check-listings holds them against
the directories and names what is missing; it exits non-zero, so it fits a hook or CI.
Every file here is hardlinked into the projects that use it — one inode, many repos.
Editing a SKILL.md with a tool that replaces the file detaches it, and every consumer
silently keeps the old content. getty-skill-library has the rules for editing safely;
manage-skills check is what proves they held.
Copyright (c) 2026 Torsten Raudssus.
This is free software; you can redistribute it and/or modify it under the terms of the Artistic License 2.0 — the Perl licence, because that is where most of this came from.
