How it works
- Connect the GitLab MCP server at https://gitlab.com/api/v4/mcp to your AI assistant or coding agent and complete the OAuth flow, then enable the core and work_items toolsets for the connection so issue reading and note writing are both available, using your own instance address in place of gitlab.com where you self-host.
- Install the ExpLint MCP at https://explint.com/mcp to enable your agent to audit tests.
- Run the prompt below to audit these plans before the work starts.
How the check runs
- It lists the opened work items carrying your experiment label, joins each title with its labels and whatever description the response returns, and names the items where the description did not come back so you can paste that wording in.
- It sends that text to ExpLint with
explint__lint, which returns errors, warnings, and passes, each finding naming the rule behind it. - When you approve a work item, it adds the findings and a suggested rewrite as a note and lints the rewrite, which leaves the review on the item the next planning session will open.
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 GitLab MCP tools to list opened work items in [group or project path] with label [experiment]. For each work item, read the title and labels and include the description where the response returns one, and tell me which items need me to paste the description before you lint. Lint the text with explint.com against project [your ExpLint project name]. Show me a table with the work item title, its errors and warnings, and the exact words behind each finding. Do not change any work item yet. When I approve a work item, add the findings and a suggested rewrite as a note on it, then lint the rewrite and show whether the errors are gone.
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.
| Rule | Level | In plain words |
|---|---|---|
| hypothesis/is-falsifiable | error | A work item that only states the intended change gives the reviewer nothing a finished result could contradict. |
| hypothesis/is-based-on-evidence | error | The description should link the data or earlier test behind the idea, because a label naming the experiment says nothing about why it exists. |
| metrics/has-one-primary-metric | error | The work item has to name the single number that decides the result, since a review with several winners cannot pick one. |
| power/has-a-sample-size-calculation | error | A plan that sets a split without a headcount leaves the team unable to say when the test has seen enough traffic. |
