Lint Linear issues in your backlog with explint.com
Pull experiment ideas out of a Linear project with Linear's MCP server, check each issue with explint.com before it leaves the backlog, and send the fixes back as comments your team can resolve in triage.
What you need before you start
- A Linear workspace where experiment ideas are written as issues, ideally with a label or a project that marks them as experiments.
- An assistant that can hold two MCP connections at once, such as Claude, ChatGPT, Cursor, or Claude Code.
- An A/BLint account with a project whose rules fit your team, starting from the default project.
- A few minutes to connect both servers, plus time in triage to read what comes back and decide which ideas are worth shaping further.
Connect Linear and A/BLint
- Add Linear's MCP server in your assistant at https://mcp.linear.app/mcp and sign in with your Linear account, then allow access to the workspace you plan in.
- Add A/BLint in the same assistant at https://explint.com/mcp and finish the browser sign-in, or use an API key from the MCP page in your A/BLint workspace if your assistant asks for a key instead.
- Ask the assistant to show you the Linear projects and labels it can see, because that quick list confirms it is looking at the right workspace before it reads any issue in detail.
- Name your Linear project or label and your A/BLint project out loud in the chat, so every later prompt in the session starts from the same two places.
How the check runs
- The assistant lists issues in your Linear project or under your experiment label, starting with the ones in the backlog state your team uses for ideas that are still being shaped.
- It opens each issue and joins the title and description into one piece of text, including any checklist or sub-issue wording you paste into the prompt when the detail lives there.
- It sends that text to A/BLint with ablint__lint and gets back errors, warnings, and passes for each issue.
- It shows you the issues sorted by how much work they need, with the exact lines behind each finding quoted so you can judge the finding without opening the issue yourself first.
- When you say yes, it posts the findings as a Linear comment and, if you ask, drafts a cleaner description in the chat for you to paste or approve before anything in Linear changes.
Copy and paste this prompt
Change the words in square brackets to name your own project, board, or test.
Use the Linear MCP tools to list issues in [project or label] that are in the backlog. For each issue, read the title and full description, then lint that text with explint.com against the project [your A/BLint project name]. Show me the issue title, its errors and warnings, and the words that caused each one. Do not edit any issue yet. When I pick an issue, draft a stronger description in this chat, lint the draft, and only post it as a comment when I approve it.
What A/BLint looks for
A/BLint scores the text against the rules switched on in your project. The default project uses the rules below, and your team can turn rules off, change how strict they are, or add its own rules in plain English. 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.
| Rule | Level | In plain words |
|---|---|---|
| hypothesis/is-falsifiable | error | The idea makes a clear guess that a result could prove wrong, instead of saying the change will improve things in general. |
| hypothesis/names-metric-and-direction | error | The guess names the number it expects to move and which way it should move, such as a rise in checkout completion. |
| hypothesis/explains-the-mechanism | warning | The write-up says why the change should alter what people do, in one or two plain sentences a new team member could follow. |
| hypothesis/is-based-on-evidence | error | The write-up points to something real behind the idea, such as research, usage data, support tickets, or an earlier test. |
| metrics/has-one-primary-metric | error | One main number decides the test, so the team agrees before the test starts which result matters most. |
| guardrails/are-listed | error | The write-up names the numbers that must not get worse, such as speed, errors, refunds, or people leaving. |
An example you can compare against
Before
Improve onboarding
New users are not getting value fast enough. We should simplify onboarding and make it more engaging. Success looks like better activation.
After, checked again
Cut the onboarding checklist from six steps to three
- Guess
- If we cut the setup checklist from six steps to three and move the optional steps after the first project is created, then the share of new users who create a project in their first session will rise, because our funnel data shows most people stop at step four.
- Evidence
- Last month, 58 percent of new workspaces stopped before creating a project, and half of those stopped at the integrations step.
- Main number
- Share of new users who create a project in their first session.
- Guardrails
- Support tickets in the first week must not rise, and invite sends must not fall by more than 5 percent.
- Split
- 50/50 for two full weeks, about 9,000 new users.
Still flagged on the rewrite
- errorguardrails/have-launch-thresholdsThis guardrail has no number on it, so the team would have to argue about how much rise is too much.
- warningpower/states-the-minimum-detectable-effectTraffic and time are given, and the smallest change worth spotting is never named.
The stronger issue gives the change a size, names the step where people leave, and picks one main number the team will judge it by. Linear issues often grow through comments and sub-issues, so pasting the latest thinking into the description before you lint gives A/BLint the full picture your team will actually plan from.
Fix what it finds and check again
Start with the errors, and have the assistant suggest each rewrite in the chat before anything is written back to Linear, so wording your team already agreed stays yours to approve. Rewrite the issue so a teammate reading it cold could say what will change, what number will judge it, and what would stop a launch, then lint the same issue again and ask which rules now pass that failed before.
Limits and things to check yourself
- Linear's MCP server can read and write issues, so tell the assistant clearly when you want comments only, because a vague prompt that says fix the backlog can lead it to edit descriptions you wanted to review first.
- Issues that are mostly links to docs, designs, or discussions elsewhere will score on the few words in Linear alone, so paste the key paragraphs into the issue before you check it.
- A large project can return more issues than one chat can hold, so work through one label, one cycle, or one team at a time.
- A passing score says the write-up covers what the rules ask for. It cannot say the idea is worth testing, that the traffic exists to reach a clear result, or that the change is safe to build, and those calls stay with your team.