Skip to main content
Claude Tag is in public beta. Features and behavior described here may change before general availability.
These prompts are ready to copy, paste, and adapt: swap in your own channel names, services, and repositories. Each comes with the reason it works, so you can keep the mechanism when you change the words.

​
First messages in a new channel

Ask what Claude can access from this channel:
Why it works: what Claude can do differs per channel, and without this grounding Claude may suggest tasks it can’t do here. Get a personalized starting point:
Why it works: it’s a discovery task with a bounded output. By asking for three tasks, you get a list you can judge in ten seconds and reuse as a menu of next tasks. Start with a low-stakes task:
Why it works: you bound the task with “since Monday”, and you can grade the result yourself because you were there.

​
Forward a message as a task

To turn an existing Slack message into a task, for example a bug report or a request someone posted, forward it to a channel Claude is in. In the message you attach when forwarding, name the deliverable and say what Claude should do if it isn’t possible. Claude reads the forwarded message, so you don’t need to retype its contents.
Why it works: by giving Claude both branches, you get a useful result whether or not a fix is possible. To hand over a discussion too long to forward, paste the thread’s link instead:
Why it works: Claude works in the thread where you pasted the link, not in the thread you linked, so it uses this channel’s connections and this channel can see the result. By asking Claude to post its plan first, you can redirect it before it starts. To read a linked thread in a public channel, Claude must be a member of that channel, and it can read a private channel’s threads only from inside that channel. If Claude says it can’t read the link, /invite @Claude in the linked public channel, or forward the messages instead.

​
Shape how the channel works

Use the prompts below to set channel-wide behavior that applies to every thread, not just yours.
Why it works: you’re explicitly telling Claude to save the rule. Claude usually doesn’t keep preferences you mention in passing.
Why it works: you’re stating standing channel behavior, so Claude applies it beyond the current conversation.
Why it works: Claude already picks up untagged posts when it judges a reply is warranted, and it weighs this channel-memory rule in that judgment, so teammates don’t have to remember to tag Claude on posts with a concrete ask. If you don’t specify a need, or if a teammate has already claimed the task, Claude may not respond to the message. In a channel Claude has stopped reading, mention @Claude so that it replies and starts reading the channel again.

​
Check and correct memory

Why it works: Claude decides what to save, so ask to see what it kept.
Why it works: you name the specific entry, so Claude doesn’t have to guess what’s stale the way it does with “clean up your memory”.
Why it works: when you correct Claude in a thread, you fix that thread only. With this message, Claude saves the correction and applies it in everyone’s future threads.

​
Manage routines

Create, audit, and stop the scheduled jobs Claude runs in this channel. For paste-ready schedules by scenario, like a daily standup summary or a weekly digest, see Routine recipes.
Why it works: you name the schedule and the post’s contents, so every week Claude posts the same shape and you can compare to last week. By asking for anything still unrouted, you get a sweep for dropped requests, not just a recap.
Why it works: schedules are channel state, and someone else may have set them up. Check what exists before you create a duplicate digest. When you ask in plain language from inside a thread, Claude lists that thread’s routines first and may leave out the rest of the channel’s, so send @Claude !scheduled there instead.
Why it works: you name which job. Any channel member can disable a scheduled job; you don’t need to find an admin to stop a noisy routine.

​
Fan out work across threads

Give Claude a list of independent tasks in a channel thread, and ask it to open one thread per task. Claude posts a top-level message for each task in the same channel, works in the replies under it, and replies in the thread where you asked with a link to each new thread.
Why it works: each new thread runs its own session in its own sandbox, so the tasks run at the same time and you can review each one on its own. To continue one existing discussion in a new thread instead, use !fork.

​
Steer work mid-thread

Reply in the same thread; once Claude is working there, you don’t need to @-mention it again.
Why it works: you’re replying into the session that’s running the task, with full context. If you ask in a new thread instead, Claude starts a second session that knows nothing about the first.
Why it works: when you redirect in the thread, Claude keeps everything the session has already learned. By asking for the diff first, you and the channel can review the change before Claude applies it.
Why it works: the thread is durable but the isolated workspace behind it isn’t. Anything Claude posts to the thread or pushes to a branch survives idle recycling; files that exist only in that workspace don’t.

​
Task starters, by shape

Each entry in the use case library gets one starter here; the linked page has the full setup and the reasoning behind its prompts.