Linear and CodeWords: automating without slowing it down

Linear's design premise is that most process is overhead, and teams choose it specifically because it refuses the configurability that lets a tracker accumulate ceremony. That premise should govern what you automate around it.

The failure mode is obvious once stated: bolting an elaborate automation layer onto a tool chosen for its restraint reintroduces exactly what the team was escaping. The automation worth building removes work rather than adding steps, and most of it connects Linear to things outside it rather than doing anything inside.

What we'll cover

• What Linear already does
• What the Linear API reaches
• Connecting it to CodeWords
• Seven automations worth building
• Connecting customer signal to the backlog
• What not to build
• Working with a GraphQL API
• Building it so it survives
• Limits worth knowing about
• What to build first
• Frequently asked questions

What Linear already does

Use these before building anything.

Git integration moves issues through states from branch names, pull requests, and merges, which covers most of what people build custom automation for elsewhere.

Cycles handle iteration planning, including carrying incomplete work forward, without anybody running a ceremony to do it.

Triage provides an inbox for incoming issues, which is the right destination for anything an automation creates.

Templates and issue defaults cover consistent issue creation.

SLAs and auto-close handle staleness natively on plans that include them.

If your intended automation duplicates one of these, use the native one. It is faster, it is visible to the team, and there is nothing to maintain.

What the Linear API reaches

Linear's API is GraphQL, which suits it: you request exactly the fields you need in one round trip rather than several.

Issues can be created, read, updated, and searched, including state, priority, labels, assignee, estimate, and relations.

Projects and cycles can be read with their progress, which is the raw material for reporting.

Teams and workflow states can be read, which any automation setting state needs, since state identifiers differ per team.

Comments can be read and created, which is where automated context belongs.

Attachments link external resources to an issue with a title and URL, and this is the underused capability that matters most for connecting customer signal.

Webhooks fire on issue, comment, and project events.

Issue relations express blocking and duplication, which matters for anything reasoning about dependencies.

Connecting it to CodeWords

CodeWords connects to more than 3,000 integrations, and the connection is made once and reused.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: which team, what triggers it, and what should result.
3. Authorize the connection with a Linear API key scoped to the workspace.
4. Describe the exceptions: a duplicate of an existing issue, an unknown team, a state that does not exist for that team.
5. Point it at a test team before anything reaches the real backlog.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

Seven automations worth building

Support signal into triage. A recurring support theme or a reported bug becomes an issue in triage, with the conversation attached, rather than being relayed verbally in a standup.

Customer impact on existing issues. When another customer reports the same thing, add to the existing issue rather than creating a new one, and record how many have now asked. This is the one that changes prioritisation.

Attachment enrichment. Link the support ticket, the error report, the recording, and the customer record to the issue, so whoever picks it up has the context without asking.

Duplicate detection on creation. Before an automation creates an issue, check whether a similar one exists, and comment on that instead. Automations creating issues are the main source of backlog duplication.

Release notes from completed issues. What shipped in each cycle or project, assembled and readable, so the note exists before anybody asks.

Cross-system status propagation. When an issue closes, tell whoever reported it — the support ticket, the customer, the account manager. Closing the loop is the step most commonly skipped.

Cycle reporting for people outside the team. What was committed, what completed, what carried, in a form somebody who does not open Linear can read.

Connecting customer signal to the backlog

This is where external automation earns its place, because Linear has no view of your support inbox or your customers.

Count, do not just report. "Three customers asked about this" is prioritisation input. "A customer asked about this" is an anecdote, and the backlog is full of anecdotes.

Attach rather than paraphrase. Link the actual conversation. A summary loses the detail somebody will need when they start work, and the original is a click away.

Record the value at stake where you can. Which accounts, on which plans, is the information product teams consistently lack and would use if it arrived without effort.

Add to existing issues rather than creating new ones. Otherwise the same problem appears eleven times and each instance looks minor.

Close the loop back. When the issue ships, the people who reported it should hear. This is the step that makes support willing to keep filing, and skipping it is why they stop.

What not to build

Anything adding a required field or a step. Linear's value is the absence of these, and an automation enforcing process is fighting the tool your team chose.

Status changes based on inference. State reflects a judgement about reality. Automated transitions from external signals produce a board that looks tidy and is wrong.

Notification volume. Linear is already good at notifying. Adding a second stream to chat for every issue event produces a channel people mute.

Elaborate estimation or velocity reporting. If the team wanted that, they would probably not be on Linear. Cycle reporting for outsiders is useful; a burndown nobody asked for is ceremony.

Anything that makes filing an issue harder. The ease of creating an issue is load-bearing.

Working with a GraphQL API

Linear's API being GraphQL changes how you use it, mostly for the better.

Ask for exactly what you need. One request returns the issue, its labels, its assignee, and its project, where a REST API would need several. This is the main practical benefit and it is substantial for anything assembling a report.

Complexity is metered, not just request count. A deeply nested query costs more than a shallow one, so requesting the entire object graph because you can is a way to be throttled while making very few requests.

Pagination is cursor-based, and nested connections paginate independently — an issue's comments are paginated inside a paginated list of issues, which surprises people who assumed one page covered it.

Mutations return the object, so you can confirm what was actually created rather than assuming and reading it back.

Errors can be partial. A response can carry both data and errors, and code that checks only for a failed request will treat a partially failed response as a success.

Building it so it survives

Make it safe to run twice. Check for an existing issue keyed on the source identifier before creating, and store that identifier in the issue so the check is cheap.

Create into triage, not straight into a cycle. Triage exists precisely so automated and external input can be reviewed before it becomes committed work.

Look up state IDs per team rather than hard-coding them, since they differ and an automation that works for one team will fail for another.

Comment rather than edit. An automated comment is visible and does not overwrite anybody's description.

Report the outcome. Issues created, issues updated, and duplicates avoided. The last number is the one that shows the automation is behaving.

Limits worth knowing about

Rate limits apply, and GraphQL complexity is part of the accounting, so a deeply nested query can be expensive even as a single request.

Workflow states are per team, so anything setting state needs to resolve the right identifier for the right team.

Pagination applies to issue queries, and an automation reading the first page computes its reporting from a partial view.

Webhook delivery is at-least-once, which is why idempotency matters.

The API evolves quickly. Linear ships frequently, and an automation written against a field that changes shape will need attention, which is the trade for a product that improves fast.

What to build first

Support signal into triage, with customer counting. It connects the two systems that most need connecting, it needs only create and comment permissions, and the count on an existing issue changes prioritisation conversations in a way that relaying anecdotes never does.

Two habits make the difference. Always check for an existing issue before creating one, since an automation that duplicates is worse than no automation. And build the close-the-loop half at the same time, because support will stop filing if reports disappear.

Frequently asked questions

Does Linear's Git integration cover state changes?

For the development lifecycle, largely yes — branches, pull requests, and merges move issues without any custom automation. Build externally only for transitions driven by something outside your repositories, and even then consider whether the transition should be automatic at all.

Should automation create issues directly in a cycle?

No. Create into triage, which exists for exactly this. Work arriving from outside should be reviewed before it becomes committed work, and bypassing triage is how a cycle fills with things nobody chose.

How do I avoid duplicate issues?

Search before creating, store the source identifier on the issue, and comment on the existing issue rather than creating a second. Automations are the largest source of backlog duplication precisely because they do not look first.

Can it tell the product team which issues affect the most customers?

Yes, and it is the most valuable thing here. Count the reports against each issue and record which accounts, so prioritisation uses evidence rather than whoever argued most recently. That information exists in support and never reaches the backlog on its own.

Should closing an issue notify the customer?

Notify whoever reported it internally, and let a person decide whether the customer hears. An automated "this is fixed" to a customer who reported something subtly different is a poor experience, and the support agent knows which situation it is.

Why does setting an issue state fail for one team and work for another?

Workflow states are defined per team with different identifiers. Resolve the state for the specific team rather than reusing an identifier, which is the most common cause of an automation that works in testing and fails on a second team.

Will automation make Linear feel like Jira?

Only if you build the kind of automation Linear deliberately omits. Automation connecting Linear to support, customers, and releases removes work. Automation enforcing fields, transitions, and ceremony adds exactly what the team left behind.

Does GraphQL mean I can ask for anything in one request?

You can, and complexity is metered, so an enormous nested query is throttled even though it is a single request. Ask for the fields you will use, which is usually a much smaller set than the ones available.

Why does my query return only some of the comments?

Because nested connections paginate separately from the outer list. An issue's comments are their own paginated connection inside a paginated list of issues, and the first page of each is not the whole of either.

Is there anything worth automating inside Linear itself?

Very little, and that is the point. Cycles, triage, the Git integration, and issue templates cover most of it natively. Reach for external automation when the work involves something Linear cannot see — support, customers, releases, or another system entirely.

Related reading

• Jira and CodeWords
• GitHub and CodeWords
• CodeWords integrations and templates