Build a Claude Code Skill Tree That Actually Works

A skill is a packaged instruction set for Claude. Write it once, describe what it does and when to trigger it, and Claude applies it when the moment is right.

Useful on its own. But the real leverage is skill trees - skills that call other skills.

The onboarding wizard Finlay ran live isn't one big script. It's a parent skill that asks what you need, then routes to the right sub-skill based on your answer. Install this. Configure that. Check the other thing. Each step is its own skill. The parent orchestrates the flow.

The unlock most people miss: pair a skill with a script behind it. The skill handles the human layer - questions, choices, branching logic, natural language. The script behind it handles the deterministic stuff that shouldn't depend on Claude interpreting your meaning correctly.

You get the warmth of a conversation with the reliability of code.

Practically, this means you can build: - An onboarding wizard that steps a new team member through your entire stack and catches gaps they didn't know to look for - A deployment skill that checks your code, opens the PR, and walks you through a safe merge - A review skill that bounces your work between two AI models until both sign off

All of these feel like talking to a colleague. All of them have hard logic running underneath. That combination is what makes skill trees genuinely different from prompt templates.

Here's the most important distinction in this whole setup.

Skills are probabilistic. Hooks are deterministic.

A skill tries to recognise when you want it. Most of the time it gets it right. You can always invoke manually. Fine.

A hook doesn't try. It fires on a specific event - every file write, every edit, every session start - and runs. No exceptions. Claude can't forget it. Context pressure can't push it out.

My favourite example: the em dash hook.

Claude loves em dashes. Left to its own devices it'll put one in every paragraph - which means every LinkedIn post, every client proposal, every article ends up with dashes I have to hunt and replace before anything goes out. So there's a hook that fires every single time Claude writes or edits anything. It scans for em dashes. Blocks the operation until they're removed. Claude has to fix it before it can proceed.

That sounds trivial. But multiply it across every output, every team member, every session - and it's the difference between a guideline and a real constraint.

Other hooks worth building: - Session-start context loading - injects your full business context before you type a single word, so Claude walks in briefed every time - Pre-commit checks - runs lint and typecheck before anything gets pushed, without you having to remember - Post-edit validations - catch things that should never ship regardless of what Claude was asked to do

The session-start hook came directly from studying how Anthropic uses Claude internally. When they briefly published the Claude Code source code, one practice that stood out was auto-loading context at session start. We borrowed it immediately.

Use hooks for the non-negotiables. Use skills for the flexible, contextual stuff. Together they cover almost everything.

Every session I run across any project pulls from the same place: the Hourglass Brain.

A folder of markdown files. Everything about the business: what we offer, how we price it, our design conventions, our financial model, client context, every operational decision that matters. Connected with internal links. Organised by domain. The session-start hook loads it automatically.

Claude opens a project already knowing what it's working on.

Here's why this is bigger than it sounds.

Every AI tool starts fresh. ChatGPT, Gemini, whatever - every session begins from zero. You paste context in. You re-explain the thing you explained last week. You get outputs that don't know your conventions.

A well-maintained brain changes that. Your Claude starts smart and gets smarter every session.

Fin showed me something I hadn't tried yet: opening the brain in Obsidian. Because everything is plain markdown with hyperlinks, Obsidian renders it as a graph - connected nodes, clickable relationships, everything mapped visually. You can see which client context links to which product decision, which design principle connects to which strategic north star. What started as a folder of notes looks like an actual knowledge graph.

The maintenance side matters too. A brain that only gets read eventually goes stale. We have a write-back system: when a session produces a real decision or a useful pattern, a skill routes it through an inbox and adds it to the brain. It learns from the work it's doing.

For a team, this is defs the biggest unlock. Everyone's Claude draws from the same source. No drift between what my Claude and Fin's Claude know. One brain, every session, for everyone.

Once you've built something useful, you want to share it with your team. But AI setups are fragile. One bad skill pushed to everyone's machine can break twenty workflows at once.

The Hourglass Claude Stack handles this with an experimental tier.

When someone builds a skill or hook they're happy with, they push it as experimental. It goes into the shared pool but doesn't activate for anyone automatically. Team members can opt in with one command. If enough people like it, someone promotes it to the standard stack. If not, it stays experimental or quietly disappears.

We ran this live. I pulled the latest stack update and watched new skills load in - things Finlay had promoted since my last sync. New slash commands, new hooks, new capabilities. All in a few seconds.

Think of it like a package manager for AI behaviour. You don't install every npm package automatically. You choose what fits and promote it when you've tested it. Same idea.

The next layer on top of this is `hg-daily-builds`: at the end of each day, it reads through your Claude Code session history, finds one genuine insight or novel technique you used, and posts it to a shared Slack channel. No active sharing required. You do your work and the system extracts the learning.

We're running this with the first cohort of our Claude Code course. Every day, everyone's best insight gets shared with everyone else. Automatically.

The hypothesis: a cohort of builders contributing one lesson each per day builds a compounding knowledge base faster than any one person can keep up with alone. Collective output beats individual output by a wide margin. The course is the test.

One of my favourite skills in the stack leans into something that's usually a frustration: different AI models don't agree with each other.

Claude and Codex have different opinions about code. Claude suggests one approach. Codex pushes back with another. Left to either model alone, you get a single perspective. But route your code through both deliberately and you get adversarial review - which is more valuable than any single model's take.

How it works: finish a piece of code in Claude, then run `/hg-codex-review`. It sends your code to Codex with a deliberately hostile framing - not "what could be improved" but "what's wrong with this." Codex finds issues. Claude fixes them. Codex reviews again. Back and forth - sometimes up to 25 rounds - until Codex is satisfied.

Token cost is lower than you'd expect. Codex is only reading and reviewing, not generating. Targeted patches going back to Claude are small. I'm running the full stack on $30 a month with plenty of headroom.

For any non-trivial coding task, this catches things neither model would catch alone. Different strengths, different blind spots, one result that's been stress-tested by both.

Add this to your stack.