How it works
- Connect the GitHub MCP server at https://api.githubcopilot.com/mcp/ to your AI assistant or coding agent, then sign in with OAuth where your host supports that flow or with a GitHub personal access token sent in the authorization header.
- 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 open issues carrying your experiment label, adds the Project Status field where those issues sit on a board, and joins the title and body into one text with any sub-issue titles the issue carries.
- 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 issue, it posts the findings and a suggested rewrite as a comment, then lints the rewrite so you can see whether the errors cleared.
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 GitHub MCP tools to list open issues in [owner/repository] with label [experiment], and include the Project Status field where those issues sit on a board. For each issue, read the title and full body, then lint that text with explint.com against project [your ExpLint project name]. Show me a table with the issue number, its errors and warnings, and the exact words behind each finding. Do not change any issue yet. When I approve an issue, post the findings and a suggested rewrite as a comment 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 issue that only states the intended change gives a reviewer nothing a later measurement could prove wrong. |
| hypothesis/is-based-on-evidence | error | The body should link the pull request, dashboard, or earlier experiment behind the idea, because GitHub is where that trail usually already exists. |
| metrics/has-one-primary-metric | error | The issue has to name the single number that decides the result, which is easy to lose in a body that lists several goals. |
| power/has-a-sample-size-calculation | error | A body that sets a split without a headcount leaves the team unable to say when the test has seen enough traffic. |
