AI Skills in Practice: Composing Skills — Agents, Hooks, and Pipelines

A single skill automates a single workflow. That is useful, but it is not where skills become transformative. The real power shows up when skills talk to each other.

Think about how you actually work. You do not review code in isolation — you review, then fix the issues, then run tests, then write a commit message. You do not write a blog post and stop — you write, then generate the meta description, then create the OG image, then publish. These are not independent tasks. They are pipelines where the output of one step feeds the input of the next.

This post covers three composition patterns: delegation, hooks, and pipelines. Each solves a different coordination problem.

Pattern 1: Delegation (One Skill Calls Another)

Delegation is the simplest composition pattern. One skill — the orchestrator — calls other skills to handle subtasks.

How Delegation Works

Consider a “ship feature” workflow:

Ship Feature (orchestrator)
  ├── Run tests
  ├── Code review skill → findings
  ├── If findings: fix issues
  ├── Commit skill → commit message
  ├── PR description skill → PR body
  └── Create PR

The orchestrator does not know how to review code or write commit messages. It delegates those tasks to specialized skills. Each sub-skill runs with its own prompt, references, and output contract, then returns results to the orchestrator.

Why Delegate Instead of One Big Skill?

You could write one massive skill that does everything — review, fix, commit, PR. But this fails for three reasons:

Focus degrades with scope. An AI following a 200-line prompt with fifteen responsibilities does each one superficially. An AI following a 30-line prompt with one responsibility does it thoroughly. Delegation lets each skill stay focused.

Reuse becomes possible. Your commit message skill works inside “ship feature,” but also works standalone when you just want to commit. Your code review skill works inside the pipeline, but also works when a teammate asks for a review. Delegation creates composable pieces.

Debugging gets easier. When the pipeline produces a bad PR description, you know exactly which skill to fix. In a monolithic skill, a bad output could come from any of fifteen intertwined instructions.

Delegation Design Rules

1. The orchestrator owns the sequence, not the logic. The orchestrator decides what happens in what order. The sub-skills decide how each step executes.

2. Pass explicit inputs. Do not rely on sub-skills to figure out their own context. The orchestrator should pass the specific files to review, the specific diff to commit, the specific changes to describe.

3. Handle sub-skill failures. What if the code review skill returns BLOCK? The orchestrator should not blindly continue to commit. Build branching logic: if review fails, stop and report.

Pattern 2: Hooks (Skills That Trigger Automatically)

Hooks are skills that run in response to events — not because you invoked them, but because something happened.

Pre-Action Hooks

A pre-action hook runs before an action completes, and can modify or block it.

hook: pre-commit
trigger: "Before any git commit is created"
action: |
  - Check staged files for secrets (.env, API keys, credentials)
  - Verify no files exceed 500 lines
  - Ensure commit message follows Conventional Commits format
  - If any check fails: BLOCK the commit with an explanation

Pre-commit hooks are the most common example, but the pattern extends to any action:

• Pre-push: Check that tests pass before pushing
• Pre-deploy: Verify environment variables are configured
• Pre-merge: Ensure PR has required approvals

Post-Action Hooks

A post-action hook runs after an action completes, typically to trigger follow-up work.

hook: post-file-write
trigger: "After a new file is created in src/components/"
action: |
  - Check if a corresponding test file exists
  - If not, suggest creating one with the standard test template
  - Check if the component is exported from the index file

Post-action hooks automate the “don’t forget to also…” tasks that developers routinely forget:

• Post-create-component: Remind to add exports and tests
• Post-edit-schema: Remind to create a migration
• Post-edit-api: Remind to update API documentation

Hook Design Principles

1. Hooks should be fast. A hook that adds 30 seconds to every commit will get disabled by the second day. Keep hook actions lightweight — quick checks, not full workflows.

2. Hooks should be non-blocking by default. Most hooks should warn, not block. Reserve blocking for genuinely dangerous actions (committing secrets, pushing to main without tests).

3. Hooks should be visible. When a hook triggers, the developer should know: what hook ran, why it ran, and what it found. Silent hooks that modify behavior without explanation erode trust.

4. Hooks are not skills. A hook is a guardrail — it checks a condition and responds. A skill is a workflow — it performs multi-step work. Do not turn hooks into full workflows. If a hook finds a problem, it should either block the action or invoke a skill to fix it, not try to fix it inline.

Pattern 3: Pipelines (Sequential Skill Chains)

A pipeline chains multiple skills where each step’s output feeds the next step’s input. Unlike delegation (where an orchestrator coordinates), pipelines are linear sequences.

Example: Blog Publishing Pipeline

Topic idea
    ↓
[Blog Writer Skill] → draft in Markdown
    ↓
[SEO Skill] → optimized meta description, keywords, heading structure
    ↓
[OG Image Skill] → generate social sharing image
    ↓
[Content Validator Skill] → check links, code blocks, frontmatter
    ↓
[Git Skill] → commit and push
    ↓
Published post

Each step takes the output of the previous step and transforms it. The Blog Writer produces a draft. The SEO skill reads the draft and optimizes it. The OG Image skill reads the optimized title and generates an image. And so on.

Example: Bug Fix Pipeline

Bug report
    ↓
[Debug Skill] → root cause analysis, reproduction steps
    ↓
[Fix Skill] → code changes to resolve the issue
    ↓
[Test Skill] → tests covering the bug and the fix
    ↓
[Review Skill] → self-review of the changes
    ↓
[Commit Skill] → commit with issue reference
    ↓
[PR Skill] → pull request with reproduction steps and fix explanation

Pipeline vs. Delegation: When to Use Which

Use delegation when the workflow needs decisions: “If tests fail, stop. If review passes, continue.” Use pipelines when every step always runs and each transforms the previous output.

In practice, most complex workflows combine both: a pipeline of phases, where some phases delegate to sub-skills.

Composition in Practice: A Deploy Workflow

Here is a realistic composed workflow that combines all three patterns:

Developer runs: /ship

Pipeline:
  Step 1: Pre-ship hook
    - Check for uncommitted changes
    - Verify on correct branch
    - Block if on main/master

  Step 2: Test phase (delegation)
    - Run unit tests
    - Run integration tests
    - If any fail → stop pipeline, report failures

  Step 3: Review skill
    - Self-review all changes since branch diverged from main
    - If BLOCK → stop pipeline, report findings
    - If REQUEST_CHANGES → list findings, ask to continue or fix

  Step 4: Commit skill
    - Analyze changes, generate commit message
    - Create commit

  Step 5: PR skill
    - Generate PR title and description from all commits
    - Push branch, create PR

  Step 6: Post-ship hook
    - Post PR link to team channel
    - Update ticket status

Three patterns, one workflow:

• Hooks at the boundaries (pre-ship, post-ship)
• Delegation within the test phase (orchestrating unit + integration)
• Pipeline connecting the phases (test → review → commit → PR)

Building Composed Workflows Incrementally

Do not design a six-step composed workflow on day one. Build it bottom-up:

1. Week 1: Build the commit skill. Use it standalone.
2. Week 2: Build the PR description skill. Use it standalone.
3. Week 3: Build the code review skill. Use it standalone.
4. Week 4: Notice you always run review → commit → PR in sequence. Chain them into a pipeline.
5. Week 5: Add a pre-commit hook for secret detection.
6. Week 6: Add a post-PR hook that posts to your team channel.

Each piece is tested in isolation before it joins a composition. You never debug a six-step pipeline — you debug one skill, confirm it works, and then compose it.

Composition Anti-Patterns

The God Orchestrator

An orchestrator that handles fifteen steps, with inline logic for each one. This is not delegation — it is a monolithic skill wearing a trench coat. If the orchestrator is longer than the skills it calls, something is wrong.

The Blind Pipeline

A pipeline where Step 4 has no idea what Steps 1-3 produced. Each skill should receive explicit context about what came before it. “Here is the diff” is better than “the file was probably modified earlier.”

The Notification Storm

Post-action hooks on every file change, every commit, every push. After a day, the developer has hook fatigue and ignores all notifications. Reserve hooks for actions that genuinely need attention.

The Fragile Chain

A pipeline where Step 3 fails if Step 2’s output format changes slightly. Build skills with clear output contracts (Part 3) and validate the contract at each pipeline boundary.

What You Should Build Next

If you followed Part 4 and built your first skill, you now have one working skill. Here is how to compose it:

1. Identify the skill’s neighbors. What do you typically do right before and right after this workflow?
2. Build the neighboring skills. One at a time, test each in isolation.
3. Connect them. Start with a simple two-step pipeline. Add steps as confidence grows.
4. Add guardrails. One pre-action hook for the most common mistake. One post-action hook for the most forgotten follow-up.

In Part 6, we apply everything — single skills, context files, composition patterns — to four real development workflows. No theory, just working examples you can adapt to your own projects.