Advanced Automation: Mastering Skills & Sub-Agents in Claude Cowork

If you're using Claude Cowork like a chatbot, you're using 10% of its power. The true potential unlocks when you start composing workflows using Skills and Sub-Agents.

This guide moves past the basics covered in Getting Started and Mastering the Skills System. We focus on the patterns that experienced users run daily: chaining Skills, dispatching Sub-Agents in parallel, and turning a one-off prototype into a hardened, repeatable workflow.

The Composition Model

Think of automation as building with lego blocks:

  • Skills: The "Instructions". Reusable prompt templates (e.g., "How we format code").
  • Sub-Agents: The "Workers". Parallel instances of Claude that do the work.
  • Main Agent: The "Manager". Coordinates the workers and synthesizes the result.

The difference between a beginner and a power user is not the number of prompts they know — it is whether their prompts are persistent and composable. A Skill you write once and invoke a hundred times compounds in value. A Sub-Agent pattern you reuse across projects turns Claude Cowork from a typing aid into a small automation team.

1. Mastering Skills

A Skill is just a persistent set of instructions. Instead of typing "Please format this as a table..." every time, you save a skill-table-format.md file. The next time you need that behavior, you point Cowork at the Skill and it applies the rules without you restating them.

Example: The "Code Review" Skill

Create a file skills/code-review.md:

# Code Review Standards
1. Security: Check for OWASP Top 10 vulnerabilities.
2. Performance: Flag any O(n^2) loops.
3. Style: Enforce TypeScript strict mode.
4. Output: detailed list of issues with line numbers.

Usage: "Review src/auth.ts using the code-review skill."

Chaining Skills for Multi-Step Work

A single Skill handles one concern. Real work needs several. The pattern is to chain Skills so the output of one becomes the input to the next.

A practical chain for turning raw research notes into a published draft:

  1. skill-extract-claims.md — reads a folder of PDFs and pulls out every factual claim with its source citation.
  2. skill-fact-check.md — takes the claim list and verifies each against the original document, flagging anything that cannot be traced.
  3. skill-draft-article.md — writes the article from the verified claims, following your house style and tone.
  4. skill-seo-check.md — reviews the draft for keyword coverage, heading structure, and internal links before you publish.

You do not need to write all four at once. Start with one, use it for a week, and add the next only when you feel the friction of doing that step manually again. Skills that solve a pain you have actually felt get used; skills written "just in case" tend to rot.

What Makes a Good Skill

A Skill is worth saving when the same instructions would otherwise be retyped regularly, when the output format must be consistent across runs, or when the task has enough steps that forgetting one causes rework. A Skill is not worth saving for one-off tasks — a plain prompt is cheaper to write and discard.

Keep each Skill focused on one concern. A "code review" Skill that also tries to run tests and open pull requests becomes hard to reason about. Split it into skill-code-review.md, skill-run-tests.md, and skill-open-pr.md, then chain them from the main agent.

2. Unleashing Sub-Agents

Sub-Agents allow parallel execution. This is the game changer for speed and for context hygiene.

The "Research Team" Pattern

Instead of: "Research these 5 competitors and write a report" (Serial, slow).

Do this: "Spawn 5 sub-agents. Assign each one to research ONE competitor deeply. Once all 5 report back, synthesize their findings into a comparison matrix."

Why it's better:

  1. Speed: 5 agents work at the same time.
  2. Focus: Each agent has a clean context window, focused only on one company.
  3. Quality: Less "hallucination" because context isn't overloaded.

When Parallel Helps and When It Hurts

Parallel Sub-Agents shine when the subtasks are independent — each agent can do its work without needing the others' output. Competitor research, batch file conversion, and per-chapter drafting are all good fits.

Parallel hurts when the subtasks are dependent. If step two needs the result of step one, spawning both at once wastes tokens and produces hallucinated output. In that case, run them serially, or split the work so the dependent part stays with the main agent while only the independent parts fan out.

A simple test: ask yourself "could each sub-task be handed to a different person in a different room, with no communication between them?" If yes, parallelize. If no, keep it serial.

A Real Example: Quarterly Report Synthesis

A finance team needs a quarterly report that pulls from three sources: a CRM export, a spreadsheet of expense receipts, and a folder of sales call notes. The serial approach reads each source one after another and slowly builds a single context. The parallel approach:

  1. Sub-Agent A reads the CRM export and produces a structured summary of deals closed.
  2. Sub-Agent B reads the expense spreadsheet and categorizes spend by department.
  3. Sub-Agent C reads the call notes and extracts the top three customer themes.

The main agent then merges the three summaries into the final report. Each sub-agent stays focused on one data source, the run completes faster, and the main agent's context is reserved for synthesis rather than raw data ingestion.

3. From Prototype to Script

The ultimate optimization loop (credit: John Lindquist):

  1. Prototype: Run a task manually with sub-agents. It works, but it's slow and costs tokens.
  2. Analyze: Ask Claude: "Look at how we just did this task. Write a Python/Node script to automate the mechanical parts."
  3. Harden: Save that script. Now your "Research Skill" just runs the script first, then uses AI only for the final synthesis.

Result: A workflow that is 10x faster and 10x cheaper.

Why This Loop Matters

The trap of "advanced" automation is over-engineering on the first try. You write an elaborate Skill with five Sub-Agents before you know whether the task even benefits from that structure. The prototype-first loop protects you: you prove the workflow works as a one-off, you learn where the friction is, and only then do you invest in hardening it into a script.

The script does not replace the AI — it replaces the mechanical parts (downloading files, renaming, splitting CSVs, calling APIs). The AI is still doing the part that actually requires reasoning: interpreting results, writing prose, making judgment calls. This division is what keeps cost down without sacrificing quality.

Common Pitfalls

  • Skill sprawl: Saving every prompt as a Skill clutters the workspace. Prune Skills you have not used in a month.
  • Context bleed: A Sub-Agent that tries to do too much will still hallucinate. Keep each agent's scope narrow enough to fit in its context window.
  • Forgetting to verify: Parallel agents feel productive, but their output still needs a human review step. Build verification into the chain, not after the fact.
  • Premature scripting: Do not write the automation script until the manual workflow is stable. Scripting a workflow that still changes weekly creates maintenance debt.

Next Steps

  • Start small: Pick one task you did manually this week and turn its instructions into a single Skill.
  • Add parallelism only when it pays: The first time a serial run feels too slow, identify the independent sub-tasks and split them into Sub-Agents.
  • Go deeper: Read our technical guide on Mastering the Skills System to learn about SKILL.md architecture and built-in capabilities, and see Optimizing Workflows for the broader patterns this guide builds on.