Devin in Slack: delegate a task with a useful brief

For a useful Devin Slack request, give the assistant one bounded task, the relevant repository, clear limits, and a way to check completion. Keep supervision focused on those checks, then save the result and next step outside the discussion. fenbs helps keep that lasting record available when a teammate or another AI takes over.

Devin is Cognition’s coding assistant, with cloud sessions and tools for writing, running, and testing code. Cognition’s introduction↗ (opens in a new tab) is the starting reference. Before sending a task through Slack, ask your workspace administrator to confirm the approved connection and how your team starts a request; do not guess an installation screen, mention name, or slash command.

What do you need before sending the request?

1. Confirm with your administrator that you are using your team’s approved connection and the correct destination for the task.
2. Choose one result that can be reviewed independently, such as fixing a reproducible error in one screen.
3. Identify the repository and the files or behavior that give the assistant a useful starting point.
4. Write the checks that would convince a person the task is finished.
5. Name the person responsible for answering questions and reviewing the outcome.

Do that preparation before the team discussion becomes a collection of competing requests. If three people are describing different symptoms, first agree on the one behavior to investigate. A clear opening message is easier to supervise than a task whose scope changes every few replies.

This guide covers the request and its follow-through, rather than promising one setup route across every account. The introduction does not establish a complete Slack installation or permissions checklist. Confirm those details with the person who manages your connection before sending private code or asking for changes.

What should the task brief say?

Make the message readable without the rest of the conversation. Include the symptom, expected behavior, scope, evidence, and limits. A link can point to background material, but the important instruction should be understandable in the request itself.

Goal: Fix the empty-state message on the orders search page.
Expected: A search with no matches shows the agreed message.
Where: Repository and relevant page or component.
Reproduce: Steps using approved sample data.
In scope: Find the cause and make the smallest useful fix.
Do not: Change search ranking, billing, or unrelated pages.
Check: Run the relevant test and inspect the no-results state.
Report: Changed files, checks, and anything not verified.
Ask first: If the fix requires changing the agreed behavior.

This is a hypothetical example, not a required Devin message format. Adapt the content to the work. The important distinction is between the desired result and the boundaries around it: an assistant should not have to infer whether “fix the message” also permits changing search logic.

Avoid credentials, personal records, or customer data in examples. Describe where approved test material can be found without copying its secrets into a message. Keep the request specific through file names and reproduction steps rather than through sensitive content.

How do you supervise without changing the goal?

Ask for a short account of the cause, the intended change, and the checks before accepting an outcome. If the assistant needs a decision, answer it directly and preserve the answer. Do not let a casual suggestion from someone else become the new task without agreement.

Keep one person responsible for the current instruction when several teammates are involved. Other people can contribute evidence, but the assistant needs a clear answer when two suggestions conflict. Record the agreed answer alongside the work so tomorrow’s reader does not have to resolve the argument again.

For choosing between coding tools, see Devin vs Claude Code or Devin vs GitHub Copilot. Those comparisons answer a different question from whether this particular request is ready to delegate.

How do you know the result is ready?

Review against the acceptance checks written before the work began. A finished summary should say which behavior changed, which files changed, what was tested, and what remains unverified. “Looks good” is not a useful substitute for the result of the relevant check.

For the example above, inspect a search with no matches and a search with matches. The first checks the intended repair; the second checks that ordinary use still works. If keyboard or small-screen behavior matters to your users, include it in the original request instead of treating it as an afterthought.

Keep a failed check visible even when the implementation looks plausible. Write the failure and next action clearly, then decide who should investigate. That makes the record useful for the next session and prevents an incomplete task from being mistaken for a verified fix.

What should you save after the discussion?

Save the result, the verification evidence, any decision that changed the approach, and the first unfinished action. The next reader rarely needs every conversational detour. They need enough to understand why the current outcome is the one the team accepted.

Keep reusable procedures separate from a one-time result. Cognition’s Skills guide↗ (opens in a new tab) describes procedures loaded when needed. A procedure can explain how to review this kind of change each time; the status of this particular task still belongs in its handoff. That keeps a temporary failure from becoming a permanent instruction.

If work continues after the original conversation, use the checklist for Devin sessions. For the distinction between cloud tasks and the coding environment on your computer, see Devin Desktop. Do not assume that two surfaces have the same retained information.

How to keep the outcome with fenbs

Keep the work so anyone responsible for it can continue from the right place, on another device or with another AI. A short record of the agreed result is more useful than making the next person search an old discussion for the final answer. The connection uses MCP, a standard way for AI apps to use outside tools.

1. Create a free account.
2. Add a task with the result you want and the checks you will use to review it.
3. Connect Devin to fenbs with the connection guides. For cloud Devin, an organization administrator with Manage MCP Servers permission must handle setup.
4. When the work changes, save the current result, checks, open questions, and next action with the task.
5. Ask the next connected assistant to read that record before continuing, and keep any new decision with it.

Cognition’s custom-server documentation↗ (opens in a new tab) describes that administrator requirement. fenbs does not connect to Slack or import the discussion. It keeps the work you choose to save; for a tiny task that ends in one sitting, a clear reviewed outcome in your existing workflow may be enough.

For more workflows that turn conversations into useful work, explore AI at work. Start with a small task, review the result against its checks, and leave the next reader a precise place to begin.