How it works
- Point your AI assistant or coding agent at the experiment through the Kameleoon Automation API, or paste the name, hypothesis, variations, targeting, allocation, and goals into the chat.
- 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 experiment through your API path or paste, lists the empty fields before checking anything, then builds one text headed hypothesis, variations, audience, traffic share, main goal, guardrails, and run time.
- It sends that text to ExpLint with
explint__lint, which returns errors, warnings, and passes, each finding naming the rule behind it. - You update the experiment in Kameleoon, bring the text back, and ask for a second lint, while any question about how Kameleoon works can go to its documentation server for a link.
Copy and paste this prompt
Change the words in square brackets to name your own project, board, or test.
Prompt for your assistant
Here is an experiment plan from Kameleoon, from the Automation API or pasted below. Repeat it back headed hypothesis, variations and what each changes, audience, traffic share, main goal, guardrail goals, and run time, and say which headings are empty. Lint it with explint.com against [your ExpLint project name]. Show each error and warning and the words that caused it. Do not launch anything or invent numbers I have not given you. Suggest fixes and lint again on my updated plan. Plan: [paste or name the Kameleoon experiment]
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 experiment that only promises an improvement gives Kameleoon's later results nothing to contradict. |
| guardrails/have-launch-thresholds | error | Each guardrail goal needs a number the team can compare against, since Kameleoon records the goal and the plan carries its limit. |
| variants/each-differs-from-control-stated | error | Every variation should state its own change, so the result can later be credited to one difference rather than a guess. |
| rollout/has-a-rollback-plan | error | A plan that reaches launch without the step that turns the change off leaves nobody able to act if a guardrail breaks. |
