a linear bot that spots missing context before planning

what a bot can do in Linear

issue status is only one part of readiness. the description may lack a clear outcome, or comments may contain an unresolved question. these actions let the bot gather that context without assuming it has authority over your team's priorities.

composio, the connection service dusk bot uses for apps, lists 48 Linear actions (catalog version 20261101_00, read 12 november 2026⁴). dusk bot treats 21 of them as reads, 2 as sends and the other 25 as changes. an action counts as a read only when its name starts with a read word like get, list or search, so a bot you allow only to read can never call the rest. a send is anything that reaches a person outside the app or moves money, like add reaction to comment: it waits for your Allow unless you've given that bot a daily amount it may send alone.

connect Linear

1. open Connected apps in the sidebar.
2. pick Linear and sign in on Linear's own page, so your password goes to them and never to a bot.
3. choose which bots may use it, and whether each may only read or may also change things. your bookkeeper doesn't need your Linear.
4. ask in plain words. reading and drafting happen freely; sending asks you first.

add linear in Connected apps, complete linear's sign-in and allow your planning bot to use it. give the team name and a few issue references to establish the scope. explain what your ready and blocked states mean rather than asking the bot to guess from their names.

routines to copy

these routines look for possible duplicates, cycle questions and gaps in project communication. send one to your bot, then inspect its first few runs before expanding the scope.

every monday at 10, search the acme team issues for possible duplicates of the new issue briefs i supplied. compare descriptions and comments, not just titles. list candidate pairs with their issue references, matching details and differences. label uncertain matches for my review. do not create, merge, close or edit issues.

every thursday at 2, inspect the current cycle for the acme team and read the issues we marked blocked. group the blockers by the decision or input explicitly requested in their comments. mark unclear blockers as unclear. leave linear unchanged.

every other tuesday at 4, read recent linear project updates for the projects i linked here. list projects with no update in the last two weeks, and questions that the latest update leaves open. do not publish a new update or edit a project.

what it asks you first

creating an issue and changing its priority, owner or state are tracker changes. they may not ask first. keep a reviewer on read-only access so its findings cannot quietly change the plan.

if you want it to maintain issues later, restrict its action list and say "ask me before you change anything". posting a comment is a send, so it waits for Allow unless you've set a daily sending amount. creating a project update is an app change, not a send, so it may not ask first. keep it off the bot's list, or write "ask me before you change anything". one exception: a bot on Full access with no sending rule of its own may send up to 25 a day without asking, so give full-access bots Ask every time under sending.

what it cannot do

• assign work, change priority or create issues with a read-only linear permission. a suggested issue outline in dusk chat stays within a much smaller job.
• know that a ticket is complete from its state name alone. ask for the description and comments behind a conclusion, and leave ambiguous readiness for a person to decide.
• carry out a cycle review on a sleeping laptop. desktop routines need the app open; an always-on dusk cloud machine can perform the scheduled review while you are away.

keep a blocker tied to its evidence

tell the bot which states to inspect and ask it to point to the issue or comment behind every blocker. if implementation discussion lives in github, connect that source separately before asking for code context. a title that sounds similar is not enough to declare two issues duplicates.

write the rule before allowing the update

define the fields a routine may maintain and where missing values should be reported. a team decision in notion can supply context, but the bot should not turn an old note into a new priority without your instruction. product managers can use these small reviews around planning rather than delegating every tracker change.