Lint Linear issues while the idea is still a draft

Linear's backlog moves quickly, so a lint that reads each issue where it sits keeps vague ideas from reaching the cycle.

How it works

  1. Connect Linear's MCP server at https://mcp.linear.app/mcp to your AI assistant or coding agent, then sign in with your Linear account.
  2. Install the ExpLint MCP at https://explint.com/mcp to enable your agent to audit tests.
  3. Run the prompt below to audit these plans before the work starts.

How the check runs

  1. It lists the issues in your project or under your experiment label, starting from the backlog state your team uses for ideas still being shaped, then joins each title and description into one text and adds checklist or sub-issue wording you paste in.
  2. It sends that text to ExpLint with explint__lint, which returns errors, warnings, and passes, each finding naming the rule behind it.
  3. When you approve an issue, it posts the findings as a comment there and drafts a cleaner description in chat, so the issue changes only after you have read the new wording.

Copy and paste this prompt

Change the words in square brackets to name your own project, board, or test.

Prompt for your assistant
Use the Linear MCP tools to list issues in [project or label] in the backlog. For each issue, read the title and full description, then lint that text with explint.com against project [your ExpLint project name]. Show me issue title, errors and warnings, and words behind each one. Do not edit any issue yet. When I pick an issue, draft a stronger description in chat, lint the draft, and post it as a comment only when I approve it.

What ExpLint looks for

ExpLint ships over 24 rules, and a project switches each one on or off or rewrites it in plain English. These are the rules the plans this guide reads break most often. An error means the test cannot answer its question as written, and a warning means the result will be hard to judge when it comes in.

RuleLevelIn plain words
hypothesis/is-falsifiableerrorA Linear issue that only claims the change will help leaves the cycle nothing a released result could contradict.
hypothesis/names-metric-and-directionerrorThe description needs the metric and the direction it should move, or the team reads the issue as a task rather than a test.
hypothesis/is-based-on-evidenceerrorThe issue should name the report, support thread, or earlier test behind it, since Linear's own history is where that trail usually sits.
metrics/has-one-primary-metricerrorLinear checklists tend to collect several wishes, so the issue has to say which single number decides whether the test worked.

Read more

Portrait of Kameron Tanseli

Kameron Tanseli

Founder, ExpLint

Kameron Tanseli is the founder of ExpLint and a growth engineer who has run more than 1,500 experiments across a nine-year career. As the founding growth hire at Fyxer he launched 540 experiments in a year while the company grew from $1M to $35M in annual revenue, and he now runs growth engineering at FLORA, where a one-person team ships six to eight experiments a week.

Don’t let a bad test make it to production

Install the MCP and start flagging ticket slop before it reaches your users