LLM Trunk — AI skill for Claude Code

🔀 llm-trunk

[](https://github.com/pdudotdev/llm-trunk/releases/tag/v0.1.0) [](LICENSE) [](https://github.com/pdudotdev/llm-trunk/commits/master/)

Skill-tagged routing gateway built on [LiteLLM](https://docs.litellm.ai/). Routes traffic to a specific model + effort level based on which skill was invoked - identified by the sha256 hash of that skill's `SKILL.md` body, not a prompt classifier.

▫️ **Same idea as an 802.1Q trunk port:**

• Tagged frame → VLAN ID routes it down that VLAN. Here: skill hash → routes down that skill's model/effort lane
• Untagged frame → falls back to the native VLAN. Here: falls back to untagged (e.g. Haiku, low effort)
• Unrecognized tag → dropped at the port, not forwarded. Here: catalog.yaml is the allowed-VLAN list

▫️ **"VLAN hopping" protection:**

• Can't fake owning a tag — wrong hash for a skill id gets dropped
• Headers can't self-assert one — x-skill-id/x-skill-hash are only honored from a key explicitly flagged for it (metadata: {"trust_skill_headers": true}); no key is flagged today
• Nor can a forged body — the tag isn't a secret (it's a hash of files every employee can read), so a hand-crafted block with the real file bytes hashes correctly too. Closed the same way real VLAN hopping is: not by hiding the tag, but by checking what each port (key) is actually allowed to carry — allowed_skills in a key's metadata is checked before routing, downgrading to untagged if the claimed skill isn't on it. Today's single qa-usage key is intentionally unrestricted (it legitimately needs every skill), so this isn't yet an active boundary for that key — it becomes one the moment a second, narrower-scoped key exists

📖 **Table of Contents**

• 🔀 *llm-trunk