Linear, a tool where you do not reach for the mouse

Linear, a tool where you do not reach for the mouse

Issue trackers tend to sprawl: custom fields, workflows with eight states, forms demanding completion on every change. A year in, filling out a ticket takes longer than fixing the bug.

Linear goes the other way. The concept set is narrow, every action has a keyboard shortcut, and the interface responds instantly, since changes save locally and sync in the background. That sounds like a detail and it decides whether a team actually keeps task states current.

Few concepts

An issue is the basic unit of work. It has a title, a description, a state, an assignee, and possibly an estimate. There are no twenty mandatory fields, since most things follow from context.

A cycle is a period, usually a week or two, in which the team works on a chosen set of issues. Unfinished work moves to the next one automatically, so nobody carries it over by hand.

A project is a larger whole spanning several cycles, with a deadline and progress computed from completed issues. An initiative groups projects once the organisation grows.

That split suffices for most teams and that is its virtue. A tool allowing any process ends with a process nobody understands, while here the frame is tight enough that few decisions remain.

Shortcuts and pace

The whole interface is built for the keyboard, and that is not an extra but the main way of working.

Creating an issue, changing state, assigning somebody, adding a label, and jumping to search all have single letter shortcuts. After a week the hand reaches for them without thinking, and updating state stops being an action requiring a decision.

That carries a consequence easy to miss. A tool where an update takes a second gets updated. A tool requiring a form and three fields gets updated on Friday afternoon, if at all, and then the board shows last week's state.

Search works on the same principle: one window where you type anything and go where you want. That replaces navigating a project structure nobody remembers past a hundred issues.

Repository integration

Linking issues to code changes works through a naming convention rather than through manual clicking.

A branch named after an issue identifier links to it automatically. A pull request opened from that branch moves the issue into review, and merging moves it to done. Nobody must remember to change status, since it follows from what actually happened.

git checkout -b piotr/PRJ-118-returns-handling

That convention solves the commonest problem with issue trackers: drift between what the board shows and what is in the repository. Since state follows from repository events, drift has no way to arise.

Set it up at the start, alongside the branch naming rule. A team adopting it from week one gets an accurate board for free. A team adding it six months later has three hundred issues in states that no longer match reality.

The branch name itself can be enforced on the repository side rather than left to memory.

#!/bin/sh
branch=$(git rev-parse --abbrev-ref HEAD)

if ! echo "$branch" | grep -qE '^[a-z]+/[A-Z]{2,5}-[0-9]+-'; then
  echo "Branch name must carry an issue identifier, e.g. piotr/PRJ-118-description"
  exit 1
fi

Saved as a hook run before pushing, that script stops a push from a branch named without an identifier. It costs a few lines and removes the whole class of issues left "in progress" despite a merged change.

Agents and the MCP server

The tool offers two things involving language models and they deserve distinguishing.

The first is built in features: automatically categorising incoming issues, routing them to the right team, and searching by meaning rather than by words. At several hundred issues a month, triage is a job somebody does by hand, so automating it saves real time.

The second is a server in the MCP protocol, letting a coding assistant see issues and update them. An assistant in Cursor or in a terminal can then read the description of the task you are working on and update it when finished.

{
  "mcpServers": {
    "linear": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://mcp.linear.app/sse"]
    }
  }
}

The configuration goes into your assistant's settings file, and authentication happens on the first connection, so the file holds no key at all. That property is why such an entry can live in the repository.

That changes how you work on tasks described by somebody else. Rather than pasting a description into a prompt, you name the identifier and the assistant reads the text along with comments and linked issues.

The boundary is the same as with every integration of this kind. Issue content comes from people, so an assistant should read it rather than execute it, particularly when it holds permission to change state.

For your own automation outside an assistant, reach for the client library, which gives typed access to the same data.

import { LinearClient } from '@linear/sdk'

const linear = new LinearClient({ apiKey: process.env.LINEAR_API_KEY })

const team = await linear.team('PRJ')
const issues = await team.issues({
  filter: { state: { type: { eq: 'started' } } },
  first: 50
})

for (const i of issues.nodes) {
  console.log(i.identifier, i.title, (await i.assignee)?.name ?? 'unassigned')
}

Note the await when reading the assignee. Related objects are fetched by a separate query at the moment of access, so a loop over fifty issues performs fifty one queries. On larger sets it pays to fetch the relations in one query rather than relying on the convenience of that form.

Triage, the team's inbox

Issues arrive from several sources: from support, from users, from automated alerts. Without a separate place for them they land straight on the team board and clutter the view of planned work.

Triage is that place. An issue arrives there, somebody reviews it and decides: accept into the team, reject, merge with an existing one, or defer. That takes a few minutes a day and keeps the board from becoming a list of everything anybody thought of.

Model backed features speed that stage up by proposing a category, a team, and a link to an existing issue. The proposal needs approval, so the risk is small and the saving at dozens of issues a week registers.

Settle who holds that role and when. Triage without an assigned person becomes a queue everybody sees and nobody touches, with issues sitting there for weeks, which is worse than having no such place.

Automation and integrations

Beyond repository integration the tool connects to chat, support systems, and monitoring services.

The most useful connection is team chat. An issue created from a message keeps a link to the conversation, so context survives, and state changes return to the channel. That removes the commonest question in such conversations, namely whether anybody picked it up.

The second is monitoring alerts. A failure notification creating an issue automatically means an incident leaves a trace even when nobody had time to write it up. Set a filter, though, since without one a single recurring error creates a hundred issues.

The third is your own automation through the programming interface. Issues created from a website form, synchronised with a support system, or created on a schedule for recurring tasks. With your own back end, in Hono for instance, that is a dozen or so lines of code.

Pricing

The free plan suffices for trying the tool and for a small project, and the two hundred fifty issue limit runs out faster than expected, since closed ones count too. It places no cap on workspace members at all, so the barrier here is the work rather than team size.

Between paid plans, two things usually decide: private teams, needed when some work should not be visible to everyone, and guest access for people outside the organisation. Basic model backed features are available at every level.

Annual billing is required on the lower plans, and the monthly version costs more. With a team of changing size weigh that in, since flexibility carries a price.

Linear against the alternatives

The third row is unfairly overlooked on small projects. Repository issues suffice while the team is three people and the work needs no cycle planning. A dedicated tool starts paying off once a view across repositories and planning several weeks ahead is needed.

Choosing between the first two rows comes down to who else will use it. A tool with a narrow concept set is fast for developers and too rigid for a legal or HR department, so in an organisation where one system must serve everybody, configurability wins.

Note, though, that the requirement for one system for everybody is often an assumption rather than a need. Two tools matched to two kinds of work cost more in subscription and less in the time teams lose working around a process designed for somebody else. That calculation is rarely made and usually comes out differently from what intuition about tidiness suggests.

Migrating from another tool

Moving several hundred issues sounds like the main cost and is in practice the smallest.

Import from popular tools works and carries titles, descriptions, comments, and assignments. What does not carry across are custom fields with no counterpart and states from a workflow that does not exist here. So settle in advance what each state maps onto.

The real cost is habits. A team used to filling five fields on every issue will look for them, and their absence will read as a shortcoming rather than as deliberate simplicity. That passes within two weeks, and the phase is worth announcing.

The practical order runs like this. Move one team first and work that way for a cycle or two. Then settle what is genuinely missing, since half the wish list turns out unnecessary. Only then move the rest.

Do not move everything, either. Issues older than a year that nobody has touched belong archived in the old tool rather than carried into the new one, where they obscure the picture from day one.

Common mistakes

The first is recreating the previous tool's process. An eight state workflow carried over wholesale removes the entire advantage, since the ceremony this tool was meant to prevent returns.

The second is skipping the branch naming convention. Without it, issue states must be updated by hand, which means they are stale within a month.

The third is treating a cycle as a deadline. A cycle is a work period and unfinished issues carry over. A team treating a cycle's end as a commitment starts splitting tasks artificially to fit a week.

The fourth is issues described in one sentence. That applies to every tool, and with an assistant reading descriptions through the MCP server it becomes visible immediately, since the result matches the description.

The fifth is the free plan on a project meant to grow. The issue limit counts closed ones too, so it runs out within months and the migration then happens under pressure.

The sixth is not reviewing issues older than a quarter. The list grows, and tasks nobody will do obscure the picture. Closing them quarterly is cheaper than pretending they will be done.

FAQ

What does Linear cost?

The free plan covers two teams and two hundred fifty issues. The base plan is ten dollars per person monthly and the business plan sixteen, both rates being for annual billing. Paying month to month costs more.

How does it differ from Jira?

It carries a far narrower concept set and is built for keyboard operation, so a state update takes a second rather than a minute. Jira gives configurability, reports, and the ability to serve processes outside a development team, which is absent here.

Is it worth it for a small team?

With three people and one repository, issues in the repository itself often suffice. A dedicated tool starts paying off when working across several repositories, when planning in cycles, and when somebody outside the development team needs a view of progress.

What does the MCP server give me?

It lets a coding assistant read an issue with its comments and links and update it once the work is done. Rather than pasting a description into a prompt, you name the identifier, and the result then follows directly from the issue description's quality.

Are AI features in every plan?

The basic ones, including categorising incoming issues and searching by meaning, yes. Extended capabilities belong to the higher plan, so during rollout check which of them you actually need.

Documentation sits on the project site, and current price tiers on the pricing page.