Work in the open
Claude is most useful when the work is somewhere the team can see, steer, and build on. A few mindsets make that the default rather than something you remember to do.- Work in public. Assume everyone in the channel can read the thread, including its checklist and results. Anything your team writes down, like decisions, conventions, and postmortems, is context Claude can use. Knowledge that lives in DMs or was only said aloud is invisible to it. Put anything personal in a DM instead.
- Share control. Replying in a thread someone else started is how work moves. Redirect the approach, add what the requester didn’t know, or pick up the result and run with it.
- Grant broad access. A channel with more connections (the tools an admin linked for this channel, like GitHub or Drive) produces more useful results, because Claude can join more sources together. The connections are scoped to the agent’s identity, so granting them to a channel does not expose anyone’s personal data.
- Give Claude the destination, not the route. State the outcome you want and let Claude work out the steps; the definition of done below makes that concrete.
- Tolerate the mess. A first draft posted in the thread is more useful than a polished one in a DM. The thread is the workspace, not the deliverable.
Write tasks that close
The phrasing of a task determines whether it has a verifiable end state, what form the result takes, and how Claude responds while working on it.Name the outcome, not the activity
A task like “post the project status and tag me when it’s up” has an end state Claude can verify; “look at this” does not, and invites an open-ended report. Put the verifiable outcome in the first sentence of the task.Give every task a definition of done
Starting a thread costs one sentence. Closing it costs your attention, because you read the output, decide whether it’s right, and reply. Without a stated end condition, Claude can’t declare the thread finished and you can’t stop checking it. The end condition you write determines who can close the thread, and the table matches each kind of condition to who closes it.| End condition | Who closes it | Example |
|---|---|---|
| An objective check passes | Claude, on its own | ”Done when CI is green” |
| You approve a prepared result | You, one click | ”Draft the status memo and post it here for approval” |
| You choose between options | You, one word | ”Research approaches A and B and recommend one” |
| No verifiable condition exists | No one | Reframe it as a question instead of a task |
- The condition must be observable by Claude. “Done when CI is green” requires access to CI. If the proof lives in a system the channel isn’t connected to, change the condition to one you close yourself.
- Spell out everything the condition includes. “Babysit this PR until it merges” can produce a merge the moment approvals arrive, before open review comments are addressed. If the full condition is approvals present, comments resolved, and your final go-ahead, write all three into the task.
Specify the output format for anything recurring
A monitor or digest that posts on a schedule posts to the channel repeatedly, so spell out the shape you want each post to take. Say how long each item should be, give it the status legend to use, and tell it what to leave out, so the channel can read every post at a glance.Steer Claude Tag explicitly
Claude adapts to instructions, but it won’t guess that you want it to. Tell it how to behave in this channel and ask it to remember. That works in both directions, whether you want more structure or less noise:Work in the right place
Where you start a thread determines what Claude can reach, who else can pick the work up, and which standing conventions apply.Pick the right surface
Channel access belongs to the channel, and DM access belongs to you. A channel can also be yours alone. Create one with just you and Claude in it, and it works the same way a team channel does. The table compares the three surfaces.| A team channel | Your own channel | A DM | |
|---|---|---|---|
| Access | The channel’s connections, set by an admin | The channel’s connections, set by an admin | Your own claude.ai connectors |
| Memory | Channel memory the team builds | Channel memory you build | Outside channel and workspace memory |
| Who sees the work | Everyone in the channel | You, plus anyone you invite | You |
| Billing | The organization | The organization | Your seat |
| Best for | Shared work the team should see and steer | Your own questions, digests, and follow-ups, kept where a teammate can pick them up | Personal tasks on your own connections, or data that shouldn’t run through a shared channel connection |
summarize the last week of #product-feedback. Claude’s Slack search covers public channels in this workspace from every surface, so the DM advantage is privacy of the answer, not broader reach.
Reading a channel’s full history, rather than what search finds, needs Claude to be a member of that channel. If it says it can’t read a channel, /invite @Claude from inside that channel adds it. Channels in a different workspace and Slack Connect channels stay out of reach.
When more than one surface would work, prefer a channel. Work that happens there compounds, because Claude can draw on it in later threads and teammates can find it, redirect it, or build on it.
If Claude says it can’t reach something in a channel, the channel likely wasn’t granted that access. See How agent identity works.
Teach Claude something that sticks
When Claude gets something wrong, or learns something worth keeping, where you put the fix decides who else benefits and whether you can do it yourself.| You want Claude to know | Put it in | Who can write it | Reaches |
|---|---|---|---|
| How this channel should behave: format, tone, when to respond | Channel memory (say it and ask Claude to remember) | Anyone in the channel | This channel (or workspace, from a public channel) |
| Conventions and setup for one repository: file layout, PR labels, dependencies to install | CLAUDE.md at the repo root (loaded when the repo is) | Anyone with repo write | Any session that works in that repo, from any channel |
| Standing rules for this channel that outrank memory | The Configure page, in the Channel instructions field | Channel members, unless an admin has restricted it | This channel |
| How to use a tool correctly, or follow a specific process, org-wide | A skill in your org’s plugin marketplace | An organization Owner adds it; anyone can ask Claude to open a PR proposing the change | Every channel under the scope it’s attached to |
| Standing rules across many channels | Custom instructions on a workspace or organization scope | An organization Owner, in the console | Every session in that scope |
CLAUDE.md carries setup as well as conventions. Sessions run in a sandbox with a standard set of preinstalled tools. If the repository needs more, such as a language runtime or a database client, put the install commands in CLAUDE.md, and Claude runs them when its work needs them.
A CLAUDE.md is guidance; a required status check is a gate. If a pull request must carry a label or pass a check, make that a repository rule rather than a memory note or a skill.
Configure Claude for a channel
The Configure link in the footer of any Claude reply opens a page where you tailor how Claude behaves in that channel. The page is on claude.ai, so you need to be signed in to your Claude organization to edit it, and an admin can restrict editing so the page is read-only for members. Use the Channel instructions field on that page to write standing guidance Claude reads in every new session in the channel: the channel’s purpose, its conventions, the tone replies should take, and anything Claude should do or avoid there. Channel instructions outrank channel memory and sit alongside any instructions an admin has set for the workspace or organization. Save the field and the change applies to new sessions started in the channel. The page also shows Connections, the services Claude can reach from this channel. Your organization’s admins set that list, so you can see it on this page but not change it.Keep thread count and review rate matched
Claude runs as many threads as you start. Your capacity to review them doesn’t scale the same way, because every thread that needs your judgment routes through you serially. Three conventions keep the queue manageable:- One channel per project. Threads and the project’s working context stay in one place, and a glance at the channel shows the project’s state.
- Batch your reviews. Several threads in one sitting costs less than the same number spread across the day, because each return is a context reload.
- Mark closed threads. React ✅ to anything you consider done, and tell your digest routine to skip them.
Related resources
- Use case library: the full setups these habits make reliable
- What Claude Tag remembers: make corrections stick