Claude Cowork
Claude on multi-step knowledge work through a managed task loop: briefs, decomposition (with a runnable planner), plugins/skills, checkpoints, and team playbooks.
Learning objectives
- Explain Cowork vs Claude Code (project vs codebase).
- Run a multi-step task loop that manages files and deliverables.
- Extend Cowork with plugins and skills.
- Manage a responsible multi-step project as a lead.
code/ak3-claude-cowork/. Python runs offline; configs are ready to use.1 · What Cowork is essential
Claude Cowork is Claude on multi-step knowledge work — research, drafting, organizing files, producing deliverables — through a managed task loop. Where Claude Code targets a codebase, Cowork targets a project: documents, data, and outputs.
This is the whole shape of how Cowork gets a big piece of knowledge work done. Read it left to right: it's a pipeline where each box hands its result to the next, and it's the same plan → act → observe agent loop you saw in Chapter 4 — just aimed at documents and deliverables instead of source code.
- Project brief (first box) — this is your input: the goal you type in, e.g. "make me a vendor-risk summary". Nothing happens until you give a clear brief.
- Break into tasks — Cowork turns that one goal into an ordered plan (a numbered to-do list). You get to see this list before any work starts.
- Work each (files, tools) — Cowork does the tasks one by one, reading files and calling
skills+plugins(its add-on abilities). This is where the actual effort happens. - Checkpoint — a deliberate pause to review. A human looks at the work-so-far and says continue or fix. This stops small mistakes from snowballing.
- Deliverables (last box) — the finished outputs: the docs, CSVs, or files you asked for.
In short: Every arrow means "pass the result forward". If you remember one thing: a brief becomes a plan, the plan becomes work, the work is checkpointed, and the checkpointed work becomes your deliverables.
2 · A task loop, end to end essential
Running a responsible multi-step project
- Give a clear brief with the deliverable and constraints.
- Let Cowork decompose it; review the task list before it runs.
- It works each task — reading files, calling tools/skills — producing artifacts.
- Checkpoint at milestones: review, correct, approve the next stage.
- Collect deliverables; verify facts and sources before relying on them.
brief.md> Project: quarterly vendor-risk summary.
> Deliverable: a 2-page markdown brief + a CSV of high-risk vendors.
> Inputs: the PDFs in ./vendor-reports/
> Constraints: cite the source file for every claim; NO contact names/emails (PII);
> flag anything you're unsure about.
> Checkpoint after the task list — I'll approve before you start.
This is not code — it's the brief you hand to Cowork, written in plain markdown (the > at the start of each line is just markdown's way of quoting a block). A good brief is the single biggest lever on quality: the clearer you are about what you want and what the rules are, the better the result.
- Project — one line naming the goal ("quarterly vendor-risk summary"). It tells Cowork the overall mission before any detail.
- Deliverable — exactly what you want back: "a 2-page markdown brief + a CSV of high-risk vendors". Naming the concrete outputs stops Cowork from guessing the format.
- Inputs — where the source material lives ("the PDFs in
./vendor-reports/"). Cowork reads from here instead of inventing facts. - Constraints — the rules it must not break: cite the source file for every claim, exclude personal info (PII = names/emails), and flag anything it's unsure about. These are your guardrails.
- Checkpoint — the last line asks Cowork to stop after making the task list so you can approve the plan before it does the work.
What the output means: There's no program output here — this text is the input. When you paste it into Cowork, its first response is a proposed task list built from these five parts.
Try this: Rewrite this brief for a task you actually have (say "summarize last month's support tickets"). Keep the same five parts — Deliverable, Inputs, Constraints, Checkpoint — and notice how much less the tool has to guess.
3 · Decompose a project (the planning step) intermediate
Cowork's first move is turning a brief into a task list. Modeling that decomposition shows what a good plan looks like — and lets you sanity-check scope before work starts.
plan.pydef plan(brief):
"""Turn a brief into ordered tasks with dependencies."""
tasks = [
{"id": 1, "do": "read all vendor PDFs", "needs": []},
{"id": 2, "do": "extract risk factors per vendor","needs": [1]},
{"id": 3, "do": "classify high-risk vendors", "needs": [2]},
{"id": 4, "do": "write the 2-page brief", "needs": [3]},
{"id": 5, "do": "produce the CSV", "needs": [3]},
]
# topological order (deps before dependents)
order, done = [], set()
while len(done) < len(tasks):
for t in tasks:
if t["id"] not in done and all(n in done for n in t["needs"]):
order.append(t["id"]); done.add(t["id"])
return order, tasks
order, tasks = plan("vendor-risk")
print("execution order:", order)
print("parallelizable:", [t["id"] for t in tasks if t["needs"] == [3]])
execution order: [1, 2, 3, 4, 5]
parallelizable: [4, 5]This runnable Python models the "Break into tasks" box from the diagram: it turns a brief into an ordered task list where some tasks depend on others. The point is to see what a good plan looks like and to work out a safe order to run things in.
tasksis a list of dictionaries. Each task has anid, ado(what it is), andneeds— the list of task ids that must finish first. Task 1 ("read all vendor PDFs") needs nothing; task 2needs [1], and so on.- The
while len(done) < len(tasks)loop keeps going until every task is scheduled.doneis a set of ids already placed in the order. - Inside,
all(n in done for n in t["needs"])asks "are all of this task's prerequisites already done?". Only then is the task appended toorderand added todone. This is called a topological order — dependencies always come before the tasks that rely on them. - At the end it prints the execution order and the
parallelizabletasks — the ones whoseneedsare exactly[3], meaning once task 3 is done they could run at the same time.
What the output means: execution order: [1, 2, 3, 4, 5] — a safe sequence where nothing runs before its prerequisites. parallelizable: [4, 5] — writing the brief and producing the CSV both only depend on task 3, so they don't have to wait for each other.
Try this: Change task 5's needs to [4] (produce the CSV only after the brief) and re-run. Task 5 will move to the end and drop out of the parallelizable list, because it now waits on task 4.
4 · Plugins & skills intermediate
Cowork is extended two ways. Plugins add capabilities/integrations (a data source, a tool). Skills (K4) are reusable instruction sets that teach Cowork how to do a recurring task your way.
| Extension | Adds | Example |
|---|---|---|
| Plugin | a capability/integration | read from a ticketing system |
| Skill | know-how for a recurring task | "how we write incident reports" |
| File workflow | structured inputs/outputs | folder of PDFs → CSV + brief |
5 · Advanced — checkpoints & course-correction advanced
Long autonomous runs need checkpoints: review intermediate artifacts at milestones and correct course before errors compound. Model a checkpoint gate so a run can't blow past a milestone unreviewed.
checkpoint.pydef checkpoint(stage, artifact_ok, human_approved):
if not artifact_ok:
return "HALT — artifact failed quality check; fix before continuing"
if not human_approved:
return f"PAUSE at '{stage}' — awaiting human approval"
return f"proceed past '{stage}'"
print(checkpoint("task-list", True, True))
print(checkpoint("draft-brief", True, False))
print(checkpoint("draft-brief", False, True))
proceed past 'task-list'
PAUSE at 'draft-brief' — awaiting human approval
HALT — artifact failed quality check; fix before continuingThis models the Checkpoint box from the diagram: a small gate function that decides whether a long run is allowed to move past a milestone. The whole idea is to stop an autonomous run from blowing through a stage that hasn't been checked.
def checkpoint(stage, artifact_ok, human_approved):takes the milestone name and two yes/no flags — was the work good (artifact_ok), and did a human approve it (human_approved).- The checks run in order of severity. First
if not artifact_ok:— if the work failed its quality check, return HALT immediately; nothing else matters. - Next
if not human_approved:— the work is fine but no human has signed off yet, so return PAUSE and wait. Thef"...{stage}..."is an f-string that drops the stage name into the message. - If it gets past both checks, both flags were true, so it returns proceed. Guarding the good outcome last is a common, safe pattern: refuse first, allow only when everything passed.
What the output means: Three lines, one per call: proceed past 'task-list' (all good), PAUSE at 'draft-brief' (quality ok but no human approval), and HALT — artifact failed quality check (quality failed, so approval is ignored).
Try this: Call checkpoint("final", False, False) and predict the result before running. It returns HALT — because the quality check is tested first, a failing artifact halts the run no matter what the human says.
6 · Professional — responsible multi-step work professional
Guardrails for long runs: scope tightly, checkpoint at milestones, keep a human in the loop for irreversible/outward-facing steps, and always verify facts. Same safety discipline as Ch 8, applied to knowledge work.
7 · Tech-lead — Cowork playbooks for the team tech-lead
A lead turns recurring knowledge work into reusable playbooks: a standard brief template + a Skill (K4) encoding the house method + required checkpoints. Then anyone can run "the incident-report project" or "the vendor-risk project" consistently.
Exercise AK3.1 — Run a small project
Context: Delegating a real multi-step task to Cowork is where framing, checkpoints, and discernment meet — the constraint (cite sources / exclude PII) is exactly the kind of guardrail an autonomous run must honor.
Your task: Give Cowork a real multi-step task with a concrete deliverable and a constraint (cite sources / exclude PII), sketch its task plan, require a checkpoint after the task list, review the output, and note one fact you had to correct.
Requirements:
- The task has a concrete named deliverable and an explicit constraint (cite sources or exclude PII)
- Sketch the task plan in the shape
plan.pyproduces - Require a checkpoint after the task list, before execution proceeds
- Review the produced output against the deliverable and the constraint
- Record at least one fact you had to correct during the run
💡 Hint: Pick a task with a checkable constraint so reviewing the output is concrete — the correction you catch is the point of the exercise.
🪜 Practice ladder beginner → industry
Six graded exercises, easy to real-world. Try each before opening its solution.
Context: Cowork runs an autonomous task loop, so the quality of the outcome is bounded by how clearly you frame the deliverable — a named artifact and explicit done-criteria give it a target and a stopping condition.
Your task: Turn a fuzzy goal into a Cowork task with a clear deliverable and explicit done-criteria.
Requirements:
- The task names a concrete artifact to produce (e.g. a specific file at a path)
- It lists what the artifact must contain, not just a vague topic
- It states an explicit "done when…" completion condition
- The framing is something the autonomous loop can work toward and know it finished
- Contrast the fuzzy version with the framed one
💡 Hint: Ask what file should exist when it's done and how you'd know it's finished — those two answers are the whole reframing.
Show solution
A good Cowork task states the outcome and how to know it's done:
Fuzzy: "look into our onboarding"
Framed: "Produce a Markdown report at docs/onboarding-audit.md that:
- lists every step in the current onboarding flow,
- flags steps with no owner or no success metric,
- recommends one improvement per flagged step.
Done when the report covers all steps and is committed."Cowork runs an autonomous task loop, so the quality of the outcome is bounded by how clearly you frame the deliverable and the done-criteria. A named artifact and explicit "done when…" give it a target to work toward and a way to know it has finished.
Context: Cowork plans before acting, and the plan is what makes the work reviewable before any code exists — it also exposes ordering, so you can catch a wrong sequence early.
Your task: For a small project, write the ordered, dependency-aware decomposition Cowork should produce before executing.
Requirements:
- Break the task into ordered steps
- Each step notes its dependencies (which earlier step it needs)
- Include context-gathering, implementation, test, and doc/commit steps as appropriate
- The ordering is defensible — e.g. commit waits on green tests; docs can start once the feature exists
- The plan is reviewable before any code is written
💡 Hint: Write each step with a "depends on" note; the dependencies, not the numbering, are what reveal the real order.
Show solution
The planning step turns one task into an ordered, dependency-aware list:
Task: "Add a /health endpoint with tests and docs."
Plan:
1. Read the existing router + test setup. (context)
2. Add GET /health returning {status:"ok"}. (depends on 1)
3. Write a test asserting 200 + body. (depends on 2)
4. Run the suite; fix until green. (depends on 3)
5. Document the endpoint in README. (depends on 2)
6. Commit on a branch; summarize the change. (depends on 4,5)Decomposition makes the work reviewable before execution and exposes ordering: docs (5) can proceed once the endpoint exists (2), but the commit (6) must wait for green tests (4). Review the plan and correct the approach before any code is written.
Context: Long autonomous runs drift, and checkpoints are what convert a black-box run into a steerable one — correcting at the nearest checkpoint preserves the context already built instead of restarting from scratch.
Your task: Design where Cowork should checkpoint in a multi-step run and how you course-correct without starting over.
Requirements:
- Checkpoint after the plan (before any edit) to approve or redirect the approach
- Checkpoint after each state-changing step with a brief status and what's next
- On a failing check, stop and surface the failure — do not paper over it
- Course-correct by replying to the nearest checkpoint so the run resumes from there
- Explain why this is cheaper than restarting: it keeps the accumulated context
💡 Hint: Put checkpoints at natural boundaries — right after the plan and after anything that changes state — and steer from the last good one.
Show solution
Insert checkpoints at natural boundaries and steer from the last good one:
Checkpoint policy for a multi-step run:
- After the PLAN (before any edit) -> approve/redirect the approach.
- After each step that changes state -> brief status + what's next.
- On a failing check -> STOP and surface the failure,
do not paper over it.
Course-correct: reply to the checkpoint ("skip step 3, the API changed;
use v2 instead") — the run resumes from there, keeping
the context it already built, instead of restarting.Checkpoints convert a black-box run into a steerable one: you approve the plan up front, get status at state changes, and are stopped (not silently worked-around) on failures. Correcting at the nearest checkpoint preserves the accumulated context — far cheaper than restarting.
Context: Cowork gains capability from both skills and plugins, and choosing between them comes down to one question: is the gap missing knowledge or a missing action?
Your task: Explain when to reach for a skill versus a plugin, and sketch the boundary between them.
Requirements:
- A skill supplies task-specific guidance/know-how Claude loads when relevant (e.g. a
SKILL.md) - A plugin / MCP tool supplies a capability the harness executes (e.g. talk to Jira or an internal API)
- A reusable prompt for a common task is a slash command, not a full skill
- State the decision rule: choose by whether the gap is knowledge or an action
- Give a concrete example on each side of the boundary
- Note that current plugin/skill packaging details should be verified in the docs
💡 Hint: If the missing piece is "how we do it," that's a skill; if it's "reach that system," that's a tool/plugin.
Show solution
Skills add know-how; plugins add tools/integrations:
Need Reach for
------------------------------------ ---------------------------------
"Follow our report format / workflow" Skill (SKILL.md: instructions +
optional bundled scripts, loaded
on demand — see ak4-agent-skills)
"Talk to Jira / our internal API" Plugin / MCP tool (a capability
the harness executes)
"Reusable prompt for a common task" Slash commandA skill is task-specific guidance Claude loads when relevant (how your team writes a runbook); a plugin/tool is a capability that performs an action (querying Jira). Choose by whether the gap is knowledge or an action. Verify the current plugin/skill packaging details in the docs.
Context: The more autonomy you grant an agent on a real repo, the more the guardrails matter: bound the blast radius, gate the irreversible steps behind a human, and make the work auditable.
Your task: Write the responsibility checklist for running Cowork on a production repository.
Requirements:
- Work on a branch, never the default branch
- Read-only by default; destructive actions require explicit approval
- Keep secrets out of prompts and out of any artifact it writes
- Checkpoint before irreversible steps (deploy, delete, external send)
- Verify with the project's own tests/lint — trust the output, not the claim
- Leave an audit trail (plan + status + summary in the PR) and require human review before merge
💡 Hint: Think blast radius, human gates, and audit trail — each item should limit scope, gate an irreversible action, or leave evidence.
Show solution
Responsibility = scope limits, human gates, and an audit trail:
Responsible Cowork run:
[ ] Work on a branch, never the default branch.
[ ] Read-only by default; destructive actions need explicit approval.
[ ] Keep secrets out of prompts and out of any artifact it writes.
[ ] Checkpoint before irreversible steps (deploy, delete, external send).
[ ] Verify with the project's own tests/lint — trust the output, not the claim.
[ ] Leave an audit trail: plan + status + final summary in the PR.
[ ] Human reviews the PR before merge.The more autonomy you grant, the more the guardrails matter: bound the blast radius (branch, read-only default), gate the irreversible steps behind a human, and make the work auditable so a reviewer can see what was done and why before it ships.
Context: Standardizing which classes of work go to Cowork is what makes quality independent of who ran the task — delegate the well-specified, mechanical, verifiable work and keep judgement-heavy work interactive.
Your task: As tech lead, decide which classes of work to hand to Cowork and write a one-page playbook that scales across the team.
Requirements:
- List good fits to delegate (audits/reports, mechanical refactors with tests, doc generation, migration scaffolding, triage)
- List poor fits to keep human (architecture decisions, security-critical changes, anything unverifiable)
- Every run must include: framed task + done-criteria, a branch, a checkpoint on the plan, CI verification, and PR + human review before merge
- Standardize shared assets: version-controlled skills and plugin/MCP config so everyone gets the same tools
- The rule keys on well-specified, mechanical, and verifiable
💡 Hint: Sort candidate work by how specified, mechanical, and checkable it is — that split is the delegate-vs-keep line.
Show solution
Standardize what to delegate and the guardrails that ride along:
Team Cowork playbook
Good fits (delegate): audits/reports, mechanical refactors with tests,
doc generation, migration scaffolding, triage.
Poor fits (keep human): architecture decisions, security-critical changes,
anything with no automated verification.
Every run MUST: framed task + done-criteria; branch; checkpoint plan;
verify with our CI; PR + human review before merge.
Shared assets: version-controlled skills (team workflows) and
plugin/MCP config so everyone gets the same tools.Delegate work that is well-specified, mechanical, and verifiable; keep judgement-heavy or unverifiable work interactive. The playbook plus shared, versioned skills/tools makes the safe pattern the default for everyone, so quality doesn't depend on who ran the task.
✓ Checkpoint — you can move on when you can…
- Explain Cowork vs Claude Code.
- Write a brief and decompose it into an ordered plan.
- Distinguish plugins from skills; use checkpoints.
- Package a responsible multi-step playbook for a team.
Knowledge check check yourself
Why is a well-scoped project brief described as the single biggest lever on Cowork output quality, and what should it contain?
Show answer
Project (mission), Deliverable (concrete outputs), Inputs (where source material lives), Constraints (rules it must not break, e.g. cite sources, exclude PII), and a Checkpoint for human approval.What is the purpose of a checkpoint gate in the Cowork loop, and why is verifying a polished deliverable especially important?