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
Think about the difference between asking a colleague a question and handing them a project. A question gets you one answer in one turn — "what's our refund policy?" A project is different: "pull together a vendor-risk summary from last quarter's reports." That second request can't be answered in a single reply. It needs someone to read the source material, break the job into steps, do each step, and hand you finished documents at the end. Cowork is Claude doing that second kind of work.
Here's the analogy to hold onto: a chatbot is a conversation, but Cowork is a colleague you delegate to. When you delegate, you don't watch every keystroke — you give a brief, let them plan, check in at milestones, and review the result. The whole page is really about doing that delegation well, because delegation done badly is how you get a confident-looking deliverable full of quiet mistakes.
The common beginner mistake is treating Cowork like a fancier chat window — firing a vague one-liner and expecting magic. It's the opposite: Cowork rewards the discipline you'd use with a capable junior teammate. Spell out the goal, name the exact outputs, point at the source files, state the rules, and ask for a check-in before it commits to real work. Do that and the "managed task loop" earns its keep; skip it and you're just gambling.
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. That "project vs codebase" line is the one to remember: Claude Code lives in your source tree editing files and running tests; Cowork lives in your work, turning folders of PDFs, notes, and data into the briefs, reports, and spreadsheets a knowledge worker actually ships.
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
Imagine you've hired a sharp new analyst and it's their first day. You wouldn't dump a vague wish on them and vanish for a week. You'd give a clear assignment, look at their plan before they sink hours into it, let them work, check in at the obvious milestones, and read the final output with a critical eye. The five steps below are exactly that — the natural rhythm of delegating serious work to someone capable — written down so you run it deliberately every time instead of hoping it happens.
Why write it out at all? Because the failure mode of autonomous work is silent drift. Each step is fine in isolation, but if step 2 misread the goal, steps 3, 4, and 5 dutifully build on that mistake and you don't find out until the polished deliverable lands on your desk. The loop's job is to catch that drift early, while it's cheap to fix — which is why the two most important moments are the review the plan step and the checkpoint step, both places where a human looks before the work rolls forward.
The mistake to avoid is skipping the review points because the tool seems competent. Confidence is not correctness. A run that never pauses is a run you can't steer, and by the time you notice it went sideways you've paid for all five steps. Treat every arrow in the loop as a chance to say "yes, continue" or "no, adjust" — that optionality is the entire value of running work as a managed loop rather than one giant prompt. The recipe below is that loop stated as a checklist you can follow start to finish.
Read the top row left to right as the five steps of the loop; then look down to the review point that guards them.
- The green box (step 1) is fine — reading the source material. Then step 2 turns red: it misreads the goal. That is the original error.
- The red arrows carry that error forward: steps 3, 4 and 5 stay red because each one faithfully builds on the bad step-2 output. One mistake becomes five contaminated artifacts.
- The amber box below is the payoff: a review or checkpoint aimed at the early steps (the dashed lines) catches the drift before it propagates, when fixing it costs a single glance.
In short: Errors don't sit still in a multi-step run — they compound. Reviewing early is why the loop beats one giant prompt.
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
The cheapest moment to catch a mistake is before any work has been done. A wrong turn in the plan costs you one glance to fix; the same wrong turn discovered in the finished deliverable costs you the whole run. That's why Cowork plans out loud — it shows you the numbered to-do list first — and why this section teaches you to read that list like a foreman reading a job sheet before the crew starts.
Think of decomposition as breaking a recipe into steps, but with one extra ingredient: dependencies. You can't frost the cake before it's baked, and you can't bake it before you've mixed the batter — some steps must come after others, while some can happen side by side (grease the pan while the oven preheats). A good plan doesn't just list the steps; it records which step waits on which, so you get a safe order to run in and you spot which pieces could run in parallel. The lab below builds exactly this: tasks that each declare what they "need," and a small routine that sorts them into a runnable order.
The common trap here is confusing numbering with ordering. Writing "1, 2, 3, 4, 5" down a page feels like a plan, but the numbers are just labels — the real order lives in the dependencies. If task 5 secretly needs task 4's output but you numbered it "5" out of habit, the sequence is a lie waiting to break. This is a genuine data-structures idea in disguise: arranging tasks so every prerequisite comes before the thing that relies on it is a topological sort over a dependency graph, the same technique a build system or a DevOps deploy plan uses. Reviewing the plan at this stage is you sanity-checking that graph — is the scope right, is the order defensible, is anything missing — before a single deliverable is written.
Follow the arrows, not the numbers: each arrow runs from a task to the task that depends on it, so a valid execution order is any path that never jumps ahead of an arrow.
- The left chain — read → extract → classify — is strictly sequential: each box's
needsnames the box before it, so they must run in that order. - Task 3 fans out to two boxes: both brief (4) and CSV (5) declare
needs: 3. Neither depends on the other. - Because 4 and 5 share the same single prerequisite, they are the green "parallel" pair — the payoff the planner detects and prints.
In short: A dependency graph gives you a safe order and reveals what can run at once — that is exactly what a topological sort computes.
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
When a new hire can't finish a task, there are only ever two things missing. Either they don't know how your team does it — the format, the house style, the unwritten rules — or they can't reach something they need, like the ticketing system nobody gave them a login to. Those are completely different gaps, and you fix them in completely different ways. Cowork extends in exactly the same two directions, and telling them apart is the whole point of this section.
A skill fixes the first gap — missing know-how. It's a reusable instruction set (you'll build these properly in K4) that teaches Cowork how to do a recurring task your way: "here's how we structure an incident report," "here's the tone our briefs use." Think of it as the onboarding doc you'd hand the new hire so they stop guessing and start matching your standards. A plugin fixes the second gap — a missing ability. It adds a capability or integration, like reading from your ticketing system or calling an internal API. Think of it as handing over the keys and the login: not more knowledge, but a new action the tool can now take.
The mistake people make is reaching for the wrong one. If Cowork's reports come out in the wrong shape, no plugin will save you — that's a knowledge gap, so you write a skill. If Cowork simply can't see your Jira tickets, no amount of instruction fixes it — that's an access gap, so you install a plugin. The clean decision rule, which the table below and the K4 exercise both come back to: ask whether the gap is knowledge or an action. Knowledge → skill. Action → plugin. Keep that split straight and extending Cowork stops being fiddly and becomes obvious.
Start at the top box — Cowork is stuck — and read down the two branches to the fix each one leads to.
- The single question in the top box — knowledge or action? — is the whole decision. Everything below is just following the answer.
- The left branch ("doesn't know HOW") lands on the green Skill box: reusable instructions like your incident-report format. No new powers, just know-how.
- The right branch ("can't REACH it") lands on the amber Plugin box: a new capability such as reading your ticketing system. Not more knowledge — a new action.
In short: Wrong shape → Skill; can't see the data → Plugin. Name the gap and the choice is automatic.
| 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
A rocket bound for the Moon is off-course for almost the entire trip. What keeps it on target isn't a perfect initial aim — it's a stream of small mid-flight corrections, each one nudging it back before the drift grows. Long autonomous runs work the same way. Cowork will wander a little; the question is whether you find out at a mid-flight correction, when a one-line reply fixes it, or after it has crashed into the wrong planet. Checkpoints are those correction points.
Here's why they matter more than they look. Errors in a multi-step run don't just sit there — they compound. If step 2 quietly misclassified a vendor, step 3 builds on the bad classification, step 4 writes it into the brief, step 5 exports it to the CSV, and now the mistake is baked into five artifacts instead of one. A checkpoint is a deliberate pause that inspects the work-so-far and refuses to let the run roll forward until a human (or an automated check) says it's good. It converts a black-box run you can only accept or reject at the end into a steerable one you can nudge at every milestone.
The subtle mistake to avoid is treating a checkpoint as a rubber stamp — clicking "continue" without really looking, which throws away the entire safety net. The other half people miss is how to correct: you don't scrap the run and start over, you reply to the nearest checkpoint ("skip step 3, the API changed — use v2"), and the run resumes from there keeping all the context it already built. Restarting is expensive; steering from the last good point is cheap. The lab below models this as a tiny gate function that checks the hard, objective failure first (did the artifact pass its quality check?) and only asks about human approval once quality is satisfied — refuse-first, allow-last, the same defensive ordering you'd want guarding anything irreversible.
Read it left to right as a gauntlet: work must clear each test in order before it can move past the milestone.
- The first amber diamond-of-sorts, "artifact ok?", is the hard, objective check. A no drops straight down to the red HALT — nothing else is even considered.
- Only a yes reaches the second gate, "human ok?". A no here is the muted PAUSE: the work is fine, it just needs sign-off.
- The payoff is the far-right green proceed: both checks passed. Notice the order — quality is asked before approval, so a broken artifact can never be waved through by a hasty human.
In short: Test the irreversible/objective failure first, ask for human approval second — refuse-first ordering is why checkpoint("final", False, True) still HALTs.
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
The more capable the tool, the more it can do wrong before anyone notices. That sentence sounds cynical but it's just physics: autonomy and blast radius scale together. A colleague who can only draft a memo can't accidentally delete production; a colleague who can touch files, call APIs, and send email can. So the discipline of responsible multi-step work isn't about distrusting Cowork — it's about matching the guardrails to the amount of rope you've handed out.
The mental model professionals use is blast radius: before a run starts, ask "what's the worst thing this could touch, and how do I bound that?" You bound it three ways, and they map cleanly onto the checklist you'll practice in the ladder. First, scope tightly — work on a branch, default to read-only, so the run physically can't reach much. Second, gate the irreversible steps — a human must sign off before anything that can't be undone (a deploy, a delete, an email that leaves the building). Third, make it auditable — leave a trail of plan, status, and summary so a reviewer can reconstruct what happened and why. This is the same safety discipline as the DevOps agent in Ch 8, just pointed at documents and deliverables instead of infrastructure.
There's one trap worth naming on its own, because it catches even careful people, and the callout below drives it home: verification is not optional, and polish makes it harder, not easier. Cowork produces confident, well-formatted output — clean tables, tidy prose, an authoritative tone. That very polish is a hazard, because a wrong number in a beautiful brief reads as true. The mistake is trusting the claim instead of checking the fact: run the project's own tests, open the cited source, confirm the figure. Trust the output, never the confidence with which it's presented.
Read it from the outside in: the big red rectangle is everything a run could touch if you did nothing; each band inside is a guardrail that shrinks that danger.
- The red outer box is the raw blast radius — files, APIs, outbound email — the worst case before any control.
- The amber band (scope tightly) pulls the boundary in: work on a branch, read-only by default, so the run physically can't reach most of that surface.
- The muted band (gate the irreversible) puts a human in front of the steps that can't be undone — deploy, delete, external send.
- The innermost green band (auditable trail) is the last layer: a record of plan, status and summary so a reviewer can see what was done and why.
In short: The more autonomy you grant, the more bands you add — scope, human gate, audit trail — until the blast radius is small enough to accept.
7 · Tech-lead — Cowork playbooks for the team tech-lead
A recipe written down once feeds the whole kitchen forever; a recipe kept in one cook's head walks out the door when they do. Everything you've learned so far in this chapter is how you run a good Cowork project. This section is the tech-lead's leap: turning your personal skill into something the whole team runs the same way, every time, regardless of who's at the keyboard. That's the difference between a clever individual and a system that scales.
Why does a lead care about this specifically? Because the failure mode of "just tell people to use Cowork" is wild inconsistency — one engineer writes a tight brief with checkpoints and a verified output, another fires a vague prompt and ships whatever comes back. Same tool, wildly different quality, and the quality tracks who ran it rather than what the standard is. A playbook removes the person from the equation: a standard brief template so the framing is always complete, a Skill (K4) encoding the house method so the how-we-do-it is baked in, and required checkpoints so nobody can skip the review. Package those and "the incident-report project" or "the vendor-risk project" produces the same solid result no matter who kicks it off.
The mistake a lead makes is packaging the prompt instead of the process. Sharing a good one-off brief helps exactly once; the next task drifts back to ad-hoc. What you actually version-control is the whole apparatus — brief template, Skill, checkpoint policy, plugin/MCP config — so the safe pattern becomes the default, the path of least resistance, not a thing people have to remember to do. This is the same instinct that separates reusable code from copy-paste: capture the reusable logic (the method, the guardrails) once, keep the one-off details (this quarter's vendors) thin on top. Decide deliberately which classes of work are good fits to delegate and which stay human, write it on one page, and you've made quality a property of the team rather than of any single person.
Read left to right: reusable parts fold into one playbook, which then hands the same standard to whoever runs it.
- The left stack is what you actually version-control — the brief template, the Skill, the checkpoint policy, the plugin/MCP config. Not a one-off prompt: the whole apparatus.
- They converge into the middle Playbook box — packaged once, committed, the path of least resistance.
- The three green boxes on the right are different engineers. Because they all run the same playbook, they all get the same solid result — that is the payoff: quality becomes a property of the team, not the person.
In short: Capture the method and guardrails once; keep the per-task details thin on top. The safe pattern becomes the default for everyone.
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?