What good delegation looks like

Anthropic's description of working with Cowork is precise: "It feels much less like a back-and-forth and much more like leaving messages for a coworker."

That framing is the mental shift that separates people who get results from Cowork from people who don't. You don't talk to Cowork. You delegate to it.

What delegation actually means

Delegation has a specific structure. It is not a long prompt. It is not a short prompt. It is a brief that contains four things:

The outcome. What finished work looks like. Not how to produce it — what it is when it's done. "A spreadsheet with one row per vendor, totals by category, no duplicates." Not "open each file, then extract the columns, then..."

The constraints. What not to do. "Don't delete anything. Don't modify files in raw/. Only write new files to out/." Constraints protect you. They are not optional.

The output specification. The exact file name, format, and location. "Save to out/expense-report.xlsx." If you don't name the output, Claude will name it. Sometimes that's fine. For work you'll use repeatedly or forward to someone else, name it.

The success criteria. How you'll know it worked. "Every receipt is in the spreadsheet. The totals match. No file in raw/ has been modified." This isn't just for you — it gives Claude a target to validate against before it calls the task complete.

A well-structured delegation prompt looks nothing like a Chat message. It looks like a brief.

The compounding principle

Every power user who has spent serious time with Cowork converges on the same finding: the prompt barely matters. The pre-work determines the outcome.

Karo Zieminski, JJ Englert, the teams at ccforpms.com — they all built the same thing independently: a persistent context structure that Claude reads before starting any task. When that structure is in place, you can write a short, informal prompt and get excellent output. When it isn't, you can write a perfect prompt and get generic results.

The pre-work has three layers:

The folder structure. A dedicated ClaudeCowork/ directory with subfolders for projects, raw inputs, working files, and final outputs. Claude navigates this structure reliably when it's consistent. Pointing Cowork at your entire Documents folder on day one is how things go wrong.

The CLAUDE.md brain file. A markdown file at the root of your folder that Claude reads at the start of every session. It tells Claude who you are, how you work, who you work with, what good output looks like, and what constraints apply everywhere. JJ Englert calls it a "brain file." The ccforpms.com team calls it a "project brief." The concept is the same: persistent context that Claude can't otherwise infer.

The five context files. Your identity (role, company, priorities), your voice (how you write, with good and bad examples), your anti-slop rules (explicit bans on em dashes, hedging phrases, AI-tells), your domain knowledge (industry terms, frameworks, methodology), and your stakeholder map (key people, their roles, communication preferences). Each file Claude has to guess at degrades the output. Each file you provide sharpens it.

The pattern compounds. Better context files produce better first drafts. Better first drafts need fewer revisions. Fewer revisions mean you run more tasks. More tasks mean you learn faster what to improve.

What Module 2 builds

The rest of Module 1 is the why. Module 2 is the build.

You will create your dedicated folder hierarchy, write your CLAUDE.md brain file, and build your first context files — identity and voice. By the end of Module 2, you'll have the infrastructure that makes every subsequent Cowork session faster and better than the one before it.

That infrastructure is the course. Everything else — the prompting patterns, the skills, the automations — depends on it.