How to Tag Claude with Tasks That Can Actually Finish

Practical habits for tagging Claude in Slack, from defining task completion to choosing channels vs DMs and keeping review queues manageable.

---

You tag Claude in a Slack thread (using @Claude), walk away, and come back to... a wall of text. Not wrong, exactly. Just not done. Now you're the one stuck deciding what to do with it.

This happens more often than it should, and it's rarely Claude's fault. It's usually the task. If a request doesn't have a clear finish line, Claude can't tell when it's done, and neither can you.

The fix isn't complicated. It just takes a few habits around how you phrase tasks, where you run them, and how you manage the threads piling up. Here's what actually works.

Why some tasks never close

Claude runs every task in its own thread. That thread stays open until someone, you or Claude, can confirm the work is finished.

The problem: "look at this" has no finish line. Claude can't verify it's done, so it produces an open-ended report and the thread just sits there.

Compare that to "post the project status and tag me when it's up." That has a verifiable end state. Claude knows exactly when to stop.

The fix: put the outcome you want in the first sentence, not the activity you want Claude to perform.

Give every task a definition of done

Starting a thread takes one sentence. Closing it takes your attention, since you have to read the result and decide if it's right.

Without a clear end condition, Claude can't say "this is finished," and you can't stop checking back. There are basically four types of end conditions:

End condition	Who closes it	Example
An objective check passes	Claude, automatically	"Done when CI is green"
You approve a result	You, one click	"Draft the memo and post it for approval"
You pick between options	You, one word	"Research A and B, recommend one"
No real condition exists	Nobody	Rephrase as a question, not a task

Two things make this work in practice:

Claude has to be able to check the condition itself. "Done when CI is green" only works if Claude has access to your CI system. No access, no automatic close, so you'd close it yourself instead.

Spell out the full condition, not just part of it. "Babysit this PR until it merges" could mean Claude merges it the second approvals land, even if comments are still open. If you actually want approvals and resolved comments and your go-ahead, write all three into the task.

For anything Claude closes on its own, ask for proof: a link, a test result, a diff. Read that instead of the whole conversation.

Format recurring posts so you can skim them

If something posts on a schedule (a digest, a monitor, an alert summary) define the shape once so every future post matches it.

@Claude every 6 hours, check #alerts and post one line per item:
🔴 needs a person, 🟡 watch, 🟢 fine. Skip 🟢 unless something changed.

Once you like a post's format, you can just point at it: "use the format from your 9am post going forward."

Tell Claude how to behave in a channel

Claude won't guess what tone or structure you want. Say it once, and ask Claude to remember it.

@Claude remember for this channel: always format reports as a table,
and ask before posting anything longer than a screen.

@Claude remember for this channel: keep replies to three sentences
unless someone asks for detail.

You can check what stuck by just asking Claude what it remembers about the channel.

Channel or DM? Pick based on who needs the result

Where you start a thread decides what Claude can access and who else can see the work.

Use a channel when	Use a DM when
Work is shared or someone else might pick it up	Work is personal
Task needs the channel's tools (issue tracker, CI, warehouse)	Task needs your own personal connections
Result should be visible to the team	You're handling sensitive data
	You want a private answer about a public channel

For that last case, just name the channel inside the DM: summarize the last week of #product-feedback. Claude can search public channels from a DM, you just get a private answer instead of a public one.

One limitation: Claude needs to actually be a member of a channel to read its full history. It also can't reach channels in other workspaces or Slack Connect channels. If it says it can't read something, run /invite @Claude from inside that channel (for detailed instructions, see the Claude Tag setup guide).

When you're not sure which to use, default to the channel. Work done there compounds: Claude can reference it later, and teammates can find and build on it.

Where to put a fix so it actually sticks

When Claude gets something wrong or learns something worth keeping, where you write the correction determines who benefits from it.

Project/
├── Channel memory          → channel tone, format, when to respond
├── CLAUDE.md (repo root)   → repo conventions, PR rules, file layout
├── Skill (plugin marketplace) → org-wide tool usage and process
└── Custom instructions     → standing rules that outrank memory

You want Claude to know	Put it in	Who can write it	Reaches
Channel tone, format, response timing	Channel memory	Anyone in the channel	This channel (or workspace)
Repo conventions, PR labels, review rules	CLAUDE.md at repo root	Anyone with repo write access	Any session in that repo
Correct tool usage, org-wide process	A skill in the plugin marketplace	An Owner adds it; anyone can propose changes	Every channel under that scope
Standing rules that override memory	Custom instructions	An Owner, via console	Every session in that scope

You can write the first two yourself directly in Slack. For the others, ask Claude to draft the change as a pull request:

@Claude that worked. Open a PR to the skills repo so this query
pattern becomes part of the Datadog skill.

One distinction worth remembering: CLAUDE.md is guidance Claude follows. A required status check is a hard gate. If something absolutely must happen before a PR merges, make it a repo rule, not a memory note.

Keep your review queue from drowning you

Claude can run as many threads as you start, but your ability to review them doesn't scale the same way. Every thread needing a judgment call routes through you, one at a time.

Three habits keep that manageable:

• One channel per project. All the threads and context stay in one place, so the channel itself shows you the project's current state.
• Batch your reviews. Checking five threads back-to-back costs less mental energy than checking one every hour, since each check-in is a context reload.
• Mark closed threads. React ✔ to anything that's done, and have your digest skip anything already marked.

Q&A

1. What makes a Claude task "closeable"?

A clear, observable end state. Either Claude can verify it itself (like a passing test) or you can confirm it in one action (like approving a draft).

2. What happens if I give Claude a task with no clear end state?

It produces an open-ended report and the thread stays open indefinitely, since there's nothing for either of you to check against.

3. Should I use a channel or a DM for a task?

Use a channel if the work is shared, needs the channel's connected tools, or should be visible to teammates. Use a DM for personal or sensitive work.

4. Can Claude read private channels I haven't added it to?

No. Claude needs to be invited to a channel to read its full history. Use /invite @Claude from inside that channel (see the Claude Tag setup guide for more details).

5. Can Claude work across different Slack workspaces?

No, it can't reach channels in a different workspace, and it can't access Slack Connect channels.

6. How do I make Claude remember formatting or tone preferences?

Tell it directly and ask it to remember, for example: "remember for this channel: keep replies short." This applies at the channel or workspace level.

7. What's the difference between channel memory and a CLAUDE.md file?

Channel memory covers tone and behavior for a Slack channel. CLAUDE.md covers repo-specific conventions like file layout and PR rules, and applies wherever that repo is used.

8. Who can create a skill for Claude?

An organization Owner adds skills to the plugin marketplace, but anyone can ask Claude to draft a proposed skill change as a pull request.

9. How do I stop my Slack review queue from getting overwhelming?

Keep one channel per project, batch your reviews instead of checking constantly, and mark finished threads with a ✔ reaction.

10. Does Claude guess how I want it to behave in a channel?

No. It adapts to explicit instructions but won't assume your preferences. State them once and ask it to remember.

References

• Good habits for working with Claude Tag