Bob with Linear: turn Slack work into tracked issues

Matthew, founder of Bob · Published July 30, 2026

Short answer

Bob with Linear closes the gap between where a team talks about work and where that work is tracked. In Slack, Bob can search issues, fetch the full details of a ticket, list teams and projects, create a new issue, update an existing one, or leave a comment.

Linear is one of Bob's purpose-built connections. That matters. Bob is not guessing at raw API fields or using a generic "do something in Linear" action. He has a small, curated toolset for the common jobs, and each person connects their own Linear account so Bob acts within that person's existing permissions.

What Bob can do in Linear today

Linear's developer platform uses GraphQL for queries and mutations and supports OAuth 2.0. Bob's Linear connection exposes seven focused actions:

Action	Type	Useful for
Search issue titles	Read	Find work and check for duplicates
Get one issue	Read	Read description, status, priority, assignee, labels, and dates
List teams	Read	Resolve the right team before creating an issue
List projects	Read	Report on project state and progress
Create an issue	Write	File a bug, task, or follow-up
Update an issue	Write	Change title, description, state, assignee, or priority
Add a comment	Write	Post a visible note or status update

That is intentionally narrower than Linear's complete API. It covers the work teams delegate most often while keeping the action and approval card understandable.

Five useful Bob and Linear workflows

1. Turn a support thread into a real issue

"Read this thread, search Linear for a matching checkout timeout, and if there is no duplicate, draft a bug in the Payments team with the reproduction steps and customer impact."

Bob first searches issue titles, then prepares the new ticket with the context already present in Slack. Creating the issue is a write, so the team gets a chance to review what will be filed. The result is a linked Linear issue, not a promise that somebody will copy the thread later.

2. Prep the engineering standup

"Before standup every weekday, list the active Payments projects and summarize the urgent or blocked issues mentioned in yesterday's Slack threads."

Bob can schedule the task, read Linear project progress, collect the relevant Slack context, and post a compact brief. The report can stay read-only. Nobody has to open Linear just to discover that the same blocker was already discussed in three channels.

3. Keep customer feedback attached to the work

"Add this customer's workaround and impact to ENG-482 as a comment. Show me the exact note before you post it."

Linear supports comments through its API, and Bob's native connection exposes that mutation directly. This is useful when sales, support, or customer success has context the engineering team needs but does not live in Linear all day.

4. Update status after a release

"Check whether PR 194 fixed LIN-217. If the tests and deploy succeeded, draft a Linear comment with the evidence and move the issue to Done."

This combines GitHub or deployment data with Linear. Bob can verify the external facts first, then propose the comment and state change. The approval step shows the write, and the run receipt records which systems Bob touched.

5. Produce a project brief for leadership

"Summarize every active Linear project for the product review. Include progress, important issue changes, and customer commitments from HubSpot."

Linear knows the project state. HubSpot knows the customer commitment. Slack often holds the reason. Bob can assemble the three into one short leadership brief without turning the product review into a dashboard tour.

Personal OAuth keeps Linear's permissions intact

Each person connects Linear with OAuth. Bob stores the connection mapping, while the connection provider holds the token. When you ask Bob to read or update Linear, he resolves your personal account rather than borrowing a teammate's connection.

That preserves the boundary already set in Linear. If your Linear role cannot see a private team or update an issue, Bob does not gain a second, broader identity. A schedule or reminder uses the connection of the person who created it. Bob does not quietly fall back to whoever connected Linear first.

The practical connect flow stays in the Slack conversation:

1. Ask Bob to connect Linear, or give him a task that needs it.
2. Open the Connect Linear button Bob posts.
3. Approve Linear access on the hosted OAuth page.
4. Return to Slack and say "retry."

Reads move, writes ask

Bob's built-in policy is simple: reads run automatically and writes ask. Searching for an issue or reading a project can keep moving. Creating a ticket, changing its state, editing its fields, or posting a comment shows an approval card unless an administrator has deliberately set a narrower policy.

The approval is not the finish line. After the action runs, Bob returns the result and a receipt. The team can see that a Linear issue was created or changed, how long the task took, what it cost, and which connected tools were used.

Teams can grant Bob more autonomy for a specific Linear action after they trust the workflow. The useful default is still to prove the first few writes before widening the policy.

Where the connection stops

• Title search is not full semantic search. Bob's purpose-built search matches issue-title text. If the only relevant phrase is buried in a comment, the native search may not find it.
• Bob does not invent permissions. Linear's connected user and OAuth scopes decide what is available.
• Not every Linear object has a native Bob action. The focused tools cover issues, teams, projects, and comments, not every administrative feature in Linear's API.
• A Slack message is not automatically a ticket. Bob creates one when asked or when a team deliberately schedules or triggers that workflow.

FAQ

What can Bob do in Linear?

Bob can search issues, fetch issue details, list teams and projects, create issues, update issue fields and status, and add comments.

Does everyone share one Linear account in Bob?

No. Linear is a personal connection in Bob. Each person connects with OAuth, and Bob uses the account and permissions of the person who asked or created the automation.

Does Bob ask before changing Linear?

By default, reads run automatically and writes ask. Creating, updating, or commenting on an issue is a write, so Bob shows the proposed action for approval unless an administrator has set a narrower policy.

Can Bob prevent duplicate Linear issues?

Bob's purpose-built Linear tools tell him to search issue titles before creating a new issue. That reduces duplicates, but the result still depends on the title and team scope used in the search.

Start with the handoff your team drops most often

The best first Bob and Linear workflow is not a giant product-operations redesign. It is the handoff that already fails every week: the support thread that never became a bug, the customer detail that never reached the issue, or the release that shipped without a status update.

Give Bob one of those jobs in Slack. Check the proposed Linear write, approve it, and inspect the receipt. When it works reliably, schedule it or grant the exact action more autonomy.

Running a Jira shop instead? Read the Bob with Jira guide. For code changes, see Bob with GitHub. For engineering adoption and spend reporting, see Bob with Cursor.