How it works
- Connect the monday MCP server at https://mcp.monday.com/mcp to your AI assistant or coding agent, then sign in with OAuth 2.0 or with a personal API token sent as a bearer token, so calls follow the permissions your monday account already carries.
- 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 reads the items in your experiment group and status column, then joins the item name, description, column values, and subitem names, since a large experiment is often broken into smaller pieces there.
- 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 an item, it posts the findings and a suggested rewrite as an update on the item and lints the rewrite, which keeps the discussion next to the card.
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 monday MCP tools to read items on board [board name] in group [group name] whose Status column is [your backlog status]. For each item, read the name, description, column values, and subitems, then lint that text with explint.com against project [your ExpLint project name]. Show me a table with the item name, its errors and warnings, and the exact words behind each finding. Do not change any item yet. When I approve an item, post the findings and a suggested rewrite as an update 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 | An item that names a change and a hope gives the board nothing a finished test could contradict. |
| hypothesis/is-based-on-evidence | error | The item text should name the report or earlier test behind the idea, since column values record what is planned rather than why. |
| randomization/states-the-split | error | The traffic split has to appear in the item text even where a subitem holds the allocation, because the lint reads the text the audit hands it. |
| duration/covers-full-business-cycles | error | The item should say how many full weeks the test runs, so the status column does not become the only record of timing. |
