Check Notion experiment briefs against their status

A Notion brief carries a status property and a page of prose, and a lint against both shows which briefs are still a title with a promise.

How it works

  1. Connect the Notion MCP server at https://mcp.notion.com/mcp to your AI assistant or coding agent, then authorize the connection with OAuth so the assistant reads the pages and databases your Notion account can already reach in the workspace you select.
  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 searches the pages and databases you name for briefs whose status property marks them as still being drafted, joins the title, page content, and status into one text, and names any brief that arrives too thin to check.
  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 a brief, it adds the findings and a suggested rewrite as a comment on the page and lints the rewrite, so the brief's status can move once the errors clear.

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 Notion MCP tools to search [workspace or database name] for experiment briefs whose status property is [Draft]. For each brief, fetch the title, full page content, and database properties, then lint that text with explint.com against project [your ExpLint project name]. Show me a table with the brief title, its errors and warnings, and the exact words behind each finding. Do not change any page yet. When I approve a brief, add the findings and a suggested rewrite as a comment on its page, 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.

RuleLevelIn plain words
hypothesis/is-falsifiableerrorA brief that only argues the change will help leaves the page with nothing a finished test could contradict.
hypothesis/names-metric-and-directionerrorThe brief has to name the number and the direction it expects, or the status property becomes the only thing marking it as a test.
hypothesis/explains-the-mechanismwarningOne or two sentences on why the change should move people belong in the brief, since a reader new to the idea otherwise has to guess the reasoning.
hypothesis/is-based-on-evidenceerrorA brief with no link to research, usage data, or an earlier test reads as an opinion, which the lint marks and the status property then carries into planning.

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