PART 3: WORKFLOWS

Chapter 11: Automation, Custom Workflows, and Agents#

What It Is#

Everything covered so far in this playbook has been about using Claude Code for individual tasks. This chapter is about building systems — repeatable workflows, custom skills, automated actions, and your own custom sub-agents that put a specialist behind one-step operations.

This is where Claude Code goes from “a powerful tool I use” to “a system that works for me.” Instead of giving Claude the same ten-step instruction every time you want to add a blog post, you create a skill that does it in one command. Instead of starting every session by re-establishing context, a hook loads it automatically. Instead of manually running a multi-step content creation workflow, an agent handles the entire pipeline.

Why It Matters for Non-Technical Professionals#

Automation is the highest-leverage activity in any professional’s toolkit. Every hour you spend building a repeatable workflow saves dozens of hours over the following months. The catch has always been that building automation requires technical skill — writing scripts, configuring tools, managing dependencies.

Claude Code changes this equation. You can describe a workflow in plain English and Claude builds the automation for you. You can create custom skills by writing a markdown file (not code). You can configure hooks by editing a JSON file. And you can define custom sub-agents in plain markdown files, no code involved.

What You Need#

Plugins: - plugin-dev — For creating custom skills and commands - commit-commands — For git automation - claude-md-management — For maintaining project memory

Understanding of: - Skills (markdown files that teach Claude specialized workflows) - Hooks (automated actions triggered by events) - The CLAUDE.md system (covered in Chapter 3)

The Workflows#

Workflow 1: Creating a Custom Skill for Repetitive Tasks#

A skill is a markdown file that teaches Claude how to handle a specific type of task. Once installed, it activates automatically when you give Claude a matching instruction.

Example: The “Add Post” Skill

After building my personal website with eighty-plus blog posts, I needed a repeatable way to add new posts. Instead of re-explaining the process each time, I created an “add-post” skill.

As a Claude prompt (to create the skill):

I want to create a reusable skill for adding new blog posts to my
personal website. Here's the workflow it should codify:

1. Accept a LinkedIn post URL or pasted text
2. Extract the content and clean formatting
3. Analyze the content to assign one of these category tags:
   Startups, AI, Marketing, Fintech, Consumer, Personal
4. If no tag fits well, suggest creating a new tag
5. Generate appropriate metadata (title, date, description)
6. Create a new MDX file in /content/posts/ with the right
   frontmatter format
7. Commit the new post to git

Write this as a skill with clear instructions. Save it in a
markdown file that I can install as a Claude Code skill.

What Claude does: 1. Creates a SKILL.md file with detailed instructions 2. Includes the tagging logic, file format specifications, and workflow steps 3. Configures it as a proper Claude Code skill that activates on matching prompts

Where the file lives. Custom skills live in one of two places depending on scope:

• ~/.claude/skills/<skill-name>/SKILL.md — available in every project on your machine. Use this for skills you want across all your work (like this add-post skill, if you use it on multiple sites).
• .claude/skills/<skill-name>/SKILL.md inside a specific project folder — available only when Claude Code is launched from that folder. Use this for skills tied to one codebase or one client.

Tell Claude which one you want. For the add-post skill above, the right answer is ~/.claude/skills/add-post/SKILL.md so it is available whenever you are working on the website.

After Claude writes the file, run /reload-plugins inside Claude Code to pick up the new skill without restarting the session. You should then see the skill listed when you type / and start scrolling through available commands.

After installation, I can simply say “Add this LinkedIn post to my website” and Claude follows the entire workflow automatically.

Workflow 2: Using Hooks for Automatic Actions#

Hooks are scripts that run automatically at specific moments in Claude Code’s lifecycle. They live in the hooks section of your ~/.claude/settings.json file. Each hook triggers on a specific event: SessionStart (when you open a session), Notification (when Claude needs your attention), PreToolUse (before a tool runs), or PostToolUse (after a tool completes).

Community hook library. Before writing hooks from scratch, check https://www.aitmpl.com/hooks — a community-curated collection of 39+ ready-made Claude Code hooks. You can browse by category and install the ones that fit your workflow. This is a good way to see what is possible with hooks and to find practical examples beyond the ones in this chapter.

Example: The “Ping Me” Notification Sound

This is the simplest, most immediately useful hook. It plays a short system sound whenever Claude Code needs your attention — typically when it is waiting for a permission approval or has finished a long-running task. Without this, you have to keep watching the terminal. With it, you can switch to another window and come back when you hear the ping.

In your settings.json:

{
  "hooks": {
    "Notification": [
      {
        "matcher": "*",
        "hooks": [
          {
            "type": "command",
            "command": "afplay /System/Library/Sounds/Tink.aiff",
            "timeout": 5
          }
        ]
      }
    ]
  }
}

Add this to your ~/.claude/settings.json (merge it into the existing hooks object if one already exists). On macOS, afplay is the built-in audio player and Tink.aiff is a subtle, short tap sound. You can swap it for any sound in /System/Library/Sounds/ — Glass.aiff for a gentle clink, Ping.aiff for a classic notification, Hero.aiff for an ascending chime.

For a richer notification, combine the sound with a macOS notification banner:

In your settings.json:

"command": "afplay /System/Library/Sounds/Tink.aiff & osascript -e 'display notification \"Claude Code needs your attention\" with title \"Claude Code\"'"

This plays the sound and shows a visible notification in your Mac’s Notification Center. The & runs the sound in the background so it does not block the notification.

Other useful hook patterns: - SessionStart — Load project status, check for uncommitted changes, verify required tools are installed - PostToolUse — Auto-format files after Claude edits them (e.g., run Prettier on HTML files) - PreToolUse — Add safety checks before destructive commands

Workflow 3: Creating a Custom Sub-Agent#

A sub-agent is a separate worker with its own desk. Where a skill is a recipe your current Claude follows (same conversation, same context window, same model), a sub-agent is a second Claude with its own context, its own standing instructions, its own restricted toolbox, and, crucially, its own model. You can put a specialist on staff that runs on Haiku, costs a fraction of your main session, and physically cannot edit your files.

Custom sub-agents are plain markdown files. Project ones live in .claude/agents/ inside the folder; personal ones live in ~/.claude/agents/ and work in every project. (Earlier versions had an interactive /agents creation wizard; current versions have retired it, and the documented way to create one is the best way anyway: ask Claude.)

Here is the one I would tell every marketer to build first: a brand checker. Its job is to review any draft against your voice and style rules, and only review. It cannot touch the file.

As a Claude prompt:

Create a brand-checker sub-agent for this project in .claude/agents/.
Its job: review any draft I point it at against my style rules: [your
three or four non-negotiables: banned words, tone, sentence length,
structure]. It should report every issue with a line reference and a
suggested fix, and never edit files itself. Make it read-only and have
it run on Haiku.

What Claude creates is a file like .claude/agents/brand-checker.md:

---
name: brand-checker
description: Reviews drafts against brand voice and style rules.
  Use when asked to brand-check a draft or review its voice.
tools: Read, Grep, Glob
model: haiku
---

You are a strict brand editor. When given a draft, check it against
these rules: [your rules]. Report every violation with the line, the
problem, and a suggested fix. Do not edit any file. End with a
verdict: publish, fix first, or rewrite.

Every line of that frontmatter is doing a job. The description is how Claude knows when to hand work to this specialist without being told. The tools line is the safety rail: read-only means a review can never quietly “fix” your draft behind your back. And model: haiku is the cost lever from Chapter 17 made permanent: review is high-volume grunt work, so the cheapest fast model does it every time.

Using it:

As a Claude prompt:

Have the brand-checker review Drafts/launch-post.md.

Your main conversation stays clean. The sub-agent reads the draft and the rules in its own context window and returns only the verdict, so a fifty-file review day never clogs the conversation you are actually working in.

Skill or sub-agent? The rule of thumb: if you want this conversation to know how to do something, write a skill. If you want work done away from this conversation, because it is noisy, or should be locked down, or should run on a cheaper model, define a sub-agent. And they compose: a skill’s instructions can end with “then have the brand-checker review the result.”

One boundary worth drawing: you will sometimes see a project folder with a CLAUDE.md and a set of skills described as a “personal AI agent.” That pattern is real and valuable, but it is a workspace, not an agent: nothing in it acts on its own. Part 5, The Command Centre, is that idea built out properly. Sub-agents are the actual workers.

Workflow 4: Sub-Agents — Your Parallel Workforce#

Workflow 3 put a permanent specialist on staff. Sub-agents also work as disposable parallel labor: instead of doing everything sequentially, you dispatch tasks to ad-hoc sub-agents that run simultaneously and report back to the main agent.

Think of it like delegation in a team. You are the manager. Claude (the parent agent) is your direct report. Sub-agents are the specialists Claude brings in when the work can be split up.

Three sub-agent patterns that matter:

The Research Sub-Agent: When you need information from multiple sources, Claude can dispatch parallel research agents that each investigate a different angle. Instead of one slow sequential search, three agents search simultaneously and synthesize their findings.

As a Claude prompt:

Research three aspects of [topic] in parallel:
1. Current market landscape and key players
2. Recent developments and trends from the past 6 months
3. Expert opinions and contrarian perspectives

Dispatch each as a separate research task. Synthesize the
findings when all three are complete.

The Reviewer Sub-Agent: When Claude produces something (a website, a script, a document), a separate reviewer agent can evaluate the output with fresh eyes. The reviewer has no context about the decisions made during creation — it only sees the result. This objectivity often catches issues the parent agent is blind to.

The QA Sub-Agent: For any generated code (websites, data processing scripts, automations), a QA agent can generate tests, run them, and report failures. This is especially valuable for non-technical users who cannot manually verify code correctness.

Why sub-agents work: Sub-agents get their own isolated context. They are not influenced by the parent agent’s reasoning or biases. They can use cheaper models (Sonnet instead of Opus), making them cost-effective for focused tasks. And because they run in parallel, three five-minute tasks complete in five minutes total, not fifteen.

The key constraint: Keep sub-agent tasks simple and focused. Each sub-agent has a probability of completing correctly — say 95%. But probabilities multiply: ten sub-agents at 95% each means only a 60% chance that all ten succeed perfectly. The simpler each task, the higher the success rate. Give sub-agents one clear job each, not a complex multi-step workflow.

The one-command version: /subtask. You do not always have to describe the delegation. Type /subtask followed by the job, and Claude sends a sub-agent off with a copy of your full conversation context. You keep working; the result reports back into your session when the errand is done.

In Claude Code:

/subtask Check every link in draft.md and report which ones are broken

Do not confuse it with /fork, which sits nearby in the command list. /fork copies your entire conversation into a separate background session that keeps going on its own — nothing comes back. The test is one question: do I want the answer here? Then /subtask. Do I want to explore a different direction without disturbing this session? Then /fork.

Concrete example: Auto-Labeling Your Email Inbox

Here is a practical sub-agent workflow for everyday use. You have hundreds of emails to triage. Instead of processing them one by one, you split the inbox into chunks and dispatch parallel classifier sub-agents.

As a Claude prompt:

Fetch my last 200 unread Gmail emails. Split them into chunks
of 50 emails each. For each chunk, dispatch a sub-agent to classify
every email into one of three categories:

- Action Required — needs a response, has a deadline, or
  contains a specific request
- Waiting On — I sent something and am waiting for a reply
- Reference — newsletters, confirmations, informational alerts

After all sub-agents complete, apply Gmail labels based on the
classifications.

Four sub-agents process fifty emails each, simultaneously. What would take twenty minutes sequentially takes five. And each sub-agent makes better decisions because it is focused on a small, manageable batch rather than trying to hold two hundred emails in context.

Concrete example: The Code-Reviewer as Quality Assurance

Whenever Claude builds something for you — a website, a data processing script, a PDF generator — you can dispatch a separate reviewer sub-agent to check the work. The reviewer has zero context about how or why the code was written. It only sees the result. This objectivity is its strength.

As a Claude prompt:

Review the code at /path/to/script.py

Evaluate for:
- Correctness (logic bugs, edge cases, off-by-one errors)
- Readability (clear naming, sensible structure)
- Performance (unnecessary complexity, inefficient operations)
- Security (injection risks, hardcoded secrets)

Return a structured review with severity levels (high/medium/low)
and a final verdict: PASS, PASS WITH NOTES, or NEEDS CHANGES.

The reviewer sub-agent costs a fraction of the parent agent (it uses Sonnet, not Opus) and catches issues that the original agent might be blind to — because the original agent is biased toward its own output. Think of it as a colleague looking over your shoulder. For non-technical users, this is your safeguard against shipping broken code.

Workflow 5: Skills with Scripts — Beyond Markdown Instructions#

Skills are not limited to markdown instructions. A skill can include a scripts/ folder containing actual executable code — bash scripts, Python scripts, or any other program that Claude can run.

This is the bridge between “tell Claude what to do” and “give Claude a tool to use.” The skill’s markdown file (SKILL.md) describes the workflow and when to use the scripts. The scripts handle the procedural, repeatable parts — API calls, data transformations, file processing — that benefit from being codified rather than re-generated each time.

Example structure:

my-custom-skill/
├── SKILL.md              ← Instructions (what the skill does, when to use it)
└── scripts/
    ├── fetch-data.py     ← Python script for API calls
    ├── process.sh        ← Bash script for file processing
    └── format-output.py  ← Python script for formatting results

The SKILL.md tells Claude: “When the user asks to run this workflow, execute fetch-data.py first, then process.sh on the output, then format-output.py for the final deliverable.” Claude orchestrates the scripts while the scripts handle the heavy lifting.

Where this lives on disk. Drop the whole my-custom-skill/ folder into ~/.claude/skills/ (for a personal skill you’ll use across projects) or .claude/skills/ inside a project folder (for a skill tied to one project). Inside SKILL.md, reference bundled scripts using the ${CLAUDE_SKILL_DIR} substitution variable — for example, bash ${CLAUDE_SKILL_DIR}/scripts/fetch-data.sh — so Claude can find the scripts no matter which folder you are currently working in.

Why this matters: Scripts are deterministic. They do the same thing every time. Claude’s AI reasoning is powerful but probabilistic. By putting the repeatable parts in scripts and the judgment calls in Claude’s hands, you get the best of both worlds — reliability where you need it, intelligence where you need it.

Workflow 6: Git Automation with Commit Commands#

The commit-commands plugin simplifies version control to two commands:

/commit-commands:commit — Stages changes, writes a commit message based on what changed, and commits.

/commit-commands:commit-push-pr — Commits, pushes to GitHub, and opens a pull request.

For non-technical users, this means version control becomes invisible. You make changes through Claude Code, type /commit-commands:commit, and your work is saved with a clear description of what changed. If you are collaborating or want to deploy, /commit-commands:commit-push-pr handles the rest.

Workflow 7: Scheduled Automation with /loop#

Sometimes the best automation is not instant — it is recurring. The /loop command lets you schedule a prompt to run at regular intervals within your Claude Code session. Think of it as setting a recurring reminder that Claude acts on automatically.

The syntax is natural language:

Inside Claude Code:

/loop 5m check if the deployment finished and tell me what happened
/loop check the build every 2 hours
/loop check the build                    (defaults to every 10 minutes)
/loop 20m /review-pr 1234               (loop over another command)

You can lead with the interval (/loop 30m ...), trail with it (/loop ... every 2 hours), or omit it entirely (defaults to every 10 minutes). Supported units: seconds, minutes, hours, days. Claude tells you exactly what interval it picked.

What makes this powerful for non-technical professionals:

The /loop command turns Claude Code into a monitoring system. You do not need to write scripts, set up cron jobs, or install monitoring software. You describe what you want checked and how often, and Claude handles it.

Example: Babysitting a deployment

Inside Claude Code:

/loop 5m check the status of the GitHub Actions workflow on the
main branch. If it has completed successfully, tell me the result
and cancel this loop. If it failed, show me the error log.

Claude checks every five minutes, reports back when something changes, and you can ask it to stop when the job is done.

Example: Monitoring a PR for new comments

Inside Claude Code:

/loop 30m check PR #42 on our repo for any new comments or
review requests since the last check. Summarize any new activity.

Managing scheduled tasks: You can ask Claude in plain language — “what scheduled tasks do I have?” to list them, or “cancel the deploy check” to stop a specific loop. Each task gets an 8-character ID for easy management.

Key constraints to know: - Session-scoped: Loops live in the current session only. Closing the terminal cancels everything. - 3-day expiry: Recurring tasks automatically expire after 3 days as a safety measure. Recreate them if you need longer. - Up to 50 tasks: A session can hold up to 50 scheduled tasks simultaneously. - Fires between turns: Scheduled prompts execute between your exchanges with Claude, not while Claude is mid-response.

One-time reminders work too: You do not need /loop for one-shot tasks. Just say “remind me at 3pm to push the release branch” or “in 45 minutes, check whether the integration tests passed” and Claude schedules it automatically.

Workflow 8: Pre-Approving Trusted Tools#

Over time, the permissions.allow array in your ~/.claude/settings.json fills with approved tools. But you can also proactively configure permissions to eliminate prompts for tools you know you will use.

The approach:

As a Claude prompt:

I want to pre-approve the following tools so Claude doesn't ask
me for permission every time:

- yt-dlp (video downloads)
- ffmpeg (media processing)
- python3 (data analysis)
- git operations (commit, push, pull)
- web search
- Playwright browser actions

Add these to the `permissions.allow` array in my `~/.claude/settings.json`.

This is a one-time setup that dramatically improves the daily experience.

Pro Tips#

Tip 1: Start with automation for your most repetitive task. Identify the one workflow you do most often and build a skill or process for it first. The time investment pays off fastest.

Tip 2: Keep skills simple. A skill should handle one workflow well, not try to be a Swiss Army knife. “Add a blog post” is a good skill. “Handle all content operations” is too broad.

Tip 3: Use CLAUDE.md as your automation backbone. Many automation tasks become unnecessary when your CLAUDE.md is comprehensive. If Claude already knows your project’s conventions, file structures, and preferences, it can follow the right workflow without a separate skill.

Tip 4: Test custom workflows before relying on them. Run your custom skill or workflow a few times manually to verify it produces correct results before trusting it to run without supervision.

Tip 5: Skills are the most token-efficient way to do recurring tasks. Here is something most users do not realize: when Claude loads a skill, it only reads the front matter (the YAML header and brief description) into its context window. The full skill body is loaded only when the skill is actually invoked. Compare this to MCPs, where every tool definition sits in context from the moment the session starts — even if you never use them. This makes skills dramatically cheaper in terms of context consumption. If you have a workflow you run through an MCP tool but could codify as a skill, the skill version will leave more room in your context for actual work.

Tip 6: When an MCP tool becomes a regular workflow, wrap it in a skill. If you find yourself using a specific MCP tool repeatedly — say, a web scraping MCP that you invoke the same way every time — consider wrapping that workflow in a skill. The skill’s SKILL.md describes what to do and when, and the scripts folder can call the underlying CLI tools directly. This way, the MCP tool definitions do not consume context space in sessions where you are not using them, and the skill only loads when needed. This is an advanced optimization, but for power users with many MCPs installed, it can reclaim significant context space.

What Others Are Building with Hooks#

The hook system has spawned creative automation patterns across the Claude Code community:

Notification hooks for long-running tasks. A hook that plays a sound or shows a Mac notification when a long-running Claude task finishes. When you dispatch a complex workflow (like processing 50 documents or building a website), you can switch to other work and get notified when Claude is done. The implementation is a simple PostToolUse hook that triggers a system notification.

PreToolUse verification guards. Use PreToolUse hooks to intercept Claude before it takes certain actions. For example: before Claude deletes any file, the hook can require explicit confirmation. Before Claude runs a destructive command, the hook adds a safety check. This is particularly valuable for non-technical users who want an extra safety layer.

Ephemeral agents via hooks. Creating purpose-built agents that spin up for a specific task and disappear when done. The hook creates a temporary agent with a narrowly-scoped skill set, executes the task, and cleans up. This pattern is advanced but illustrates where automation is heading — agents that self-assemble for the task at hand.

The contrarian case for hooks over prompting. A growing voice in the community argues that hooks provide more reliable control than detailed prompting. Instead of writing elaborate instructions about what Claude should and should not do, encode the rules as hooks that automatically enforce them. For example, instead of writing “always format code before committing” in your prompt, create a PostToolUse hook that auto-formats after every code change.