Write a request Claude can work with

You have now seen Claude reply on its own, run work on a schedule, and keep going while you are away, which means you can hand it larger jobs than a single question. That kind of work benefits from a different kind of instruction than a one-off ask.

When you hand Claude a task or a responsibility rather than a question, think about what Claude would need to understand the work well enough to know when to step in, when it is done, and how to decide something when you are not around. This lesson walks through choosing the work, writing that request, and what to expect while Claude carries it out.

Step 1: Pick the work

Before you write, think through what you want, what Claude can access, and how you'll know if it worked.

• Shift from step-by-step thinking to outcome thinking: Picture delegating to someone who understands your workspace completely. What would you ask them to pull together or figure out?
• Consider the inputs your task needs and make sure Claude can reach them: Does it have access to the tools, files, and threads the work depends on? If unsure, ask @Claude what can you access from this channel? If Claude doesn't have what it needs, either move the task to a channel that does or ask your admin to connect the tool (lesson 5).
• Think about who can see the work: Check if the channel is appropriate. Sensitive work belongs in a private channel (lesson 4).

Step 2: Write the request

• State the goal, then the process that matters: Say what you're trying to accomplish and why, and what a good result looks like and where it will go. Add the steps or constraints you care about; for the rest, knowing the intent lets Claude make good calls on the details you didn't spell out.
• Point to the inputs you want Claude to use in the task: It can read the channel, search the workspace, and use that channel's connections or attached files. If you have an example of a good result, link or paste it, or tell Claude where to find it.
• Build in a way to check Claude's work: Once you've thought about what success looks like, how will you be able to tell if Claude got it right? Think about ways you can ask Claude to verify the work, like giving it a rubric for what a good result looks like, linking its sources, or separating what it verified from what it inferred.
• Tell Claude what to prioritize: State what you care about in a good response. Consider things like the audience, the level of polish, what to avoid, or which decisions to bring back to you. When Claude faces a choice you didn't expect, these help steer its judgment.

For some tasks, you may want to write the request differently:

• For big, complex tasks that need planning, ask Claude to propose an outline of its plan so you can align on an approach before it starts.
• When the work is exploratory or ambiguous, say so. Give Claude the question and why it matters, then leave room for it to propose a few directions before deciding how to execute.
• For proactive or scheduled work, tell Claude what it owns and where you decide. One way to do this is to set a north star: a person posts one ambitious, measurable goal in a channel Claude reads and pins it there. Claude in that channel can then propose work toward the goal on its own.

To learn how to set up and run a human-agent team, see the Building Effective Human-Agent Teams course. For examples, see use cases of what Claude can do.

Step 3: Let Claude work

Claude reacts to your message and posts a short note that it's started. It keeps working without you, and if you're working in a channel, anyone in it can jump in to add context or adjust Claude's plan. Everything stays in the thread, so anyone can pick up where you left off.

You'll see:

• A progress checklist, edited in place: A longer task gets one message that Claude updates as it works. Those edits send no notification, so look for items ticked off since you last checked, or say in your request that you want a message at the bigger decision points and Claude will post one in the thread.
• A new reply when Claude needs you or has a result: A question, a problem it cannot solve alone, or the finished work. Claude waits for your answer to a question.
• Quiet usually means working: If the work gets blocked, Claude usually says so in a reply rather than going silent.

Editing a message you already sent has no effect; send a new reply instead. Each top-level message starts a new task for Claude. Keep separate tasks in different threads, but remember that Claude's channel notes apply to every thread in the channel.

Step 4: Review the result

Review Claude's work before you use it, and look more closely when more is at stake. A result in a thread arrives without the dashboards or documents you would usually check it against. Because you built verification into the request, you can follow the links, files, or queries it cited to see how it reached its answer.

If a result needs adjusting, see what Claude actually did by reading its checklist. If you spot something that needs fixing:

• If Claude looked in the wrong place or couldn't reach the right one, move the task to a channel with that tool or ask your admin to connect it.
• If Claude's work is incomplete, ask which sources or channels it searched. It may have been blocked from some of the sources you would have wanted it to use, or stopped the task early.
• If your request wasn't clear, reply and rewrite it. Include what you want, the form, what to prioritize, and where to look.
• If Claude missed a pattern your team follows, including how you check work, save it to memory so everyone in the channel benefits going forward (lesson 6).

Try it

Before you move on

Key takeaway: hand over a whole task with a goal, its inputs, and a way to check it; steer in the thread; check the result before you use it.

After practicing: You will have run one real task from request to reviewed result, and saved the correction it needed for next time.