Lint Jira tickets in your backlog with explint.com

Read experiment tickets straight from a Jira backlog with Atlassian's MCP server, check each one with explint.com in the same chat, and leave a clear comment your team can act on before the ticket gets picked up.

What you need before you start

A Jira Cloud project where your experiment ideas sit as tickets, with the backlog or board your team actually plans from.
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 match how your team wants experiments written, starting from the default project.
About twenty minutes for the first run, because connecting both tools and reading the first report takes longer than the quick checks that follow once the setup is done.

Connect Jira and A/BLint

Add Atlassian's Rovo MCP server in your assistant at https://mcp.atlassian.com/v2/mcp and sign in with your Atlassian account, then allow the Jira access it asks for so it can search and read issues in your project.
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 list the tools it can now see from both servers, because seeing the Jira search tools beside the A/BLint lint tool tells you both connections worked before you trust it with real tickets.
Tell the assistant the name of your Jira project and your A/BLint project in plain words, since it needs both names to know where to read and which rules to check against.

How the check runs

The assistant searches your backlog with Jira Query Language through the Atlassian MCP server, using the search tool to find tickets with your experiment label or in the status your team uses for ideas that are not yet ready.
It opens each ticket in full and pulls together the title, the description, and the acceptance criteria into one piece of text, because A/BLint can only judge the words that are actually written down.
It sends that text to A/BLint with the ablint__lint tool and gets back a list of errors, warnings, and passes, with each finding naming the rule it relates to.
It groups the findings by ticket and shows you the weakest tickets first, so you can spend your time on the ideas that need the most work.
When you approve the wording, it adds a short comment to each Jira ticket with the findings and a suggested rewrite, which keeps the advice where the team will see it during planning.

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 Jira MCP tools to find tickets in [PROJECT KEY] with the label [experiment] and the status [Backlog]. For each ticket, read the full description and acceptance criteria, then lint that text with explint.com against the project [your A/BLint project name]. Show me a table with the ticket key, the errors and warnings for that ticket, and the exact words that caused each finding. Do not change any ticket yet. When I approve a ticket, add a comment with the findings and your suggested rewrite, and then lint the rewrite and show me whether the errors are gone.

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/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.
power/has-a-sample-size-calculation	error	The plan shows how many people the test needs, worked out from the current rate and the smallest change worth caring about.

An example you can compare against

Before

Make checkout better

We should make the checkout page better so more people buy. The new design looks cleaner and we think it will help sales. Let's test it for a couple of weeks and see what happens.

After, checked again

Test a shorter checkout form on phones

Guess: If we cut the phone checkout form from five steps to three, then checkout completion will rise, because our session recordings show people leaving at the address step when they have to retype details they already gave us.

Evidence: In the last 30 days, 41 percent of phone checkouts stopped at the address step, from our product analytics.

Main number: Checkout completion rate on phones.

Guardrails: Payment errors must not rise above 1 percent, and page load time must not get worse by more than 0.3 seconds.

Split: 50/50, about 12,000 phone checkouts, which our sample size calculation says is enough to spot a 2 point rise.

Run time: Two full weeks, then we ship if completion rises and the guardrails hold.

Still flagged on the rewrite

errordecision/has-criteria-before-launchA ship result is named, and no result that would stop the test or run it again is written down.
warningrandomization/states-the-unitThe traffic is counted in checkouts, and the plan never says whether one person can appear in both groups.

The stronger ticket names the change, the number, and the reason in its first lines, and it gives the guardrails and the run time their own lines so a reader can check them quickly. Your tickets can use your own headings and your own numbers, since A/BLint reads the meaning of the words and your team stays in charge of what a good result looks like for your product.

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 Jira, so wording your team already agreed stays yours to approve. Rewrite the ticket 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 ticket again and ask which rules now pass that failed before.

Limits and things to check yourself

The Atlassian MCP server only works with Jira Cloud, and the tools your assistant can see depend on the access your Atlassian admin has allowed, so a missing search tool usually means a permission needs turning on.
Tickets that carry their real plan in an attachment, a linked page, or a picture of a design will score as if that plan does not exist until someone pastes the words into the ticket.
Reading a whole backlog in one chat can hit the limits of either server, so lint one label or one sprint at a time and keep a regular slot for it in planning.
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.