Skip to content

Instantly share code, notes, and snippets.

@sriprasanna
Created May 6, 2026 10:45
Show Gist options
  • Select an option

  • Save sriprasanna/ef10fe43ac2de1cd97e638c5c65b430d to your computer and use it in GitHub Desktop.

Select an option

Save sriprasanna/ef10fe43ac2de1cd97e638c5c65b430d to your computer and use it in GitHub Desktop.
Composing Claude Code skills

Composing Claude Code skills

I've used Claude Code almost every day for close to a year. When Agent Skills shipped late last year, we adopted them on day one. Within a week the catalogue was a mess, with some skills doing one thing and others trying to do five, so we went back to the Unix rule. Each skill does one thing well, and if it starts doing two things, you split it.

The model started using the skills better on its own almost straight away. Claude Code skills auto-trigger, so if a skill's description matches the task, the model can pick it up without being asked. As we made each skill narrower, Claude picked the right one more often, and the auto-triggering got better too.

Once the single-purpose skills were clean, bigger workflows became much easier. You mostly write down the order things should happen.

That's not a new idea. The first time it clicked for me was in 2012, early in my career, sitting in our ThoughtWorks office in Kampala, Uganda. My tech lead Chris Ford gave a talk called Functional Composition, using Clojure to compose tiny functions into music. It blew my mind, and I still think about it. Same idea here, just with skills instead of functions.

Here's one workflow we use. This is what runs when I pick up a Linear ticket and call /linear-ticket TRA-994.

    /business-analyst        ← optional cleanup of a vague ticket
            ↓
    CLAUDE.md                ← project rules and constraints
            ↓
         (implement)
            ↓
    /verify-feature          ← agree criteria, drive Playwright in the browser
            ↓
    /commit                  ← clean, ticket-prefixed
            ↓
    /commit-push-pr          ← (plugin)
            ↓
    /check-codex-pr-reviews  ← chase Codex on the PR until 👍, unattended
            ↓
    /ask-user-for-reviews    ← request human reviewer
            ↓
    /ask-qa-to-review        ← move ticket to Ready For Testing, assign QA
            ↓
        production

Every one of these is a single-purpose skill. None of them know about the others. Each one is useful on its own. /check-codex-pr-reviews works on any PR, /ask-qa-to-review works on any branch tied to a Linear ticket, and /verify-feature can drive any browser flow once we've agreed the acceptance criteria. Only /linear-ticket knows the order. It composes the others.

This is an old rule from regular software, but AI workflows make the cost of ignoring it obvious much faster. When one skill references another, the model reads both, even when you only needed one. That extra context sticks around for the rest of the conversation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment