Lint Kameleoon experiments with explint.com before you launch
Kameleoon offers a public MCP server for its documentation, while your live experiments are read through its Automation API, so keep those two apart and check the experiment plan with explint.com before launch.
What you need before you start
- A Kameleoon account with an experiment drafted, including its variations, targeting, traffic allocation, and goals.
- API access to Kameleoon's Automation API with a client credential your developer can set up, or the experiment details copied carefully from Kameleoon into the chat.
- An A/BLint account with a project for your team, connected in the same assistant as any Kameleoon API tooling you use.
- Optional and handy on its own, Kameleoon's documentation MCP server at https://docs.kameleoon.com/mcp for looking up how a setting works while you fix a finding.
Connect Kameleoon and A/BLint
- Add A/BLint in the same assistant at https://explint.com/mcp and finish the browser sign-in, or use an API key from the MCP page in your A/BLint workspace if your assistant asks for a key instead.
- Give the assistant a way to read the live experiment. A developer can call the Kameleoon Automation API at https://api.kameleoon.com with your account credential through your own MCP or API tooling, or you can paste the experiment name, hypothesis, variations, targeting, allocation, and goals into the chat.
- If you want product help while you work, add Kameleoon's documentation MCP server at https://docs.kameleoon.com/mcp as a separate connection, and remember it answers questions about the docs while it cannot see your experiments.
- Ask the assistant to repeat the experiment plan back with headings, then name your A/BLint project before the first lint.
How the check runs
- The assistant reads the experiment through the Automation API path your team set up, or from your paste, and it lists any empty field before it checks the plan.
- It builds one text with headings for the hypothesis, the variations, the audience, the traffic share, the main goal, the guardrails, and the run time.
- It sends that text to A/BLint with ablint__lint and brings back errors, warnings, and passes.
- For any finding that turns on how Kameleoon works, it can ask the documentation MCP server for the relevant page and link you to it, which keeps product help and plan checking in the same chat without mixing them up.
- You update the experiment in Kameleoon, refresh the text, and ask for a second lint so the report you keep matches the experiment you launch.
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, read through the Automation API or pasted below. First, repeat it back with headings for hypothesis, variations and what each one changes, audience, traffic share, main goal, guardrail goals, and run time, and say which headings are empty. Then lint the full text with explint.com against the project [your A/BLint project name]. Show me each error and warning and the words that caused it. Do not launch anything and do not invent numbers I have not given you. Suggest fixes in this chat, and lint again when I give you the updated plan. Plan: [paste or name the Kameleoon experiment]
What A/BLint looks for
A/BLint scores the text against the rules switched on in your project. The default project uses the rules below, and your team can turn rules off, change how strict they are, or add its own rules in plain English. 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 | The idea makes a clear guess that a result could prove wrong, instead of saying the change will improve things in general. |
| hypothesis/names-metric-and-direction | error | The guess names the number it expects to move and which way it should move, such as a rise in checkout completion. |
| metrics/has-one-primary-metric | error | One main number decides the test, so the team agrees before the test starts which result matters most. |
| guardrails/have-launch-thresholds | error | Each guardrail has a clear limit that would stop a launch, written as a number the team can check without debate. |
| variants/each-differs-from-control-stated | error | Each version says exactly what changes, so the team can tell afterwards which change caused the result. |
| randomization/states-the-unit | error | The plan says who or what gets split into groups, such as a person, a visit, or an account, because every rate depends on that choice. |
| duration/covers-full-business-cycles | error | The test runs long enough to cover full weeks, so a busy Monday and a quiet Sunday both count in the result. |
| rollout/has-a-rollback-plan | error | The plan says how the change gets turned off quickly if it hurts people, and who can make that call. |
An example you can compare against
Before
New filters
- Hypothesis
- Better filters will help users find products.
- Variations
- Original, New filters
- Goals
- Conversion rate
- Allocation
- 50/50
After, checked again
Sticky filters on category pages
- Hypothesis
- If the filter bar stays visible while people scroll a category page, then the share of visits that use a filter and reach a product will rise, because analytics show most visits scroll past the filters and never come back to them.
- Main goal
- Share of category visits that use a filter and then open a product.
- Guardrails
- Page load time must not get worse by more than 0.2 seconds, and visits with no product view must not rise by more than 2 points.
- Versions
- Control keeps the filter bar at the top. Test keeps the same filters in a bar that stays visible while scrolling, with no change to the products or their order.
- Audience and split
- All category page visitors, split by visitor, 50/50, test accounts left out, for three full weeks.
- Stop rule
- Stop the experiment if load time breaks its limit for a full day, and the duty engineer can stop it without waiting for a meeting.
Still flagged on the rewrite
- errorpower/has-a-sample-size-calculationThree careful weeks are planned, and no count shows whether they are enough.
- warningdecision/has-criteria-before-launchStopping is nailed down, and the result that would ship the change is not.
The stronger plan describes the current page first and keeps the change to one behaviour, so the result can be read without a debate about which change did the work. It also names who can stop the test, a detail that reads as small in a plan and matters a great deal on a bad day.
Fix what it finds and check again
Start with the errors, and have the assistant suggest each rewrite in the chat before anything is written back to Kameleoon, so wording your team already agreed stays yours to approve. Rewrite the experiment plan so a teammate reading it cold could say what will change, what number will judge it, and what would stop a launch, then lint the same experiment plan again and ask which rules now pass that failed before.
Limits and things to check yourself
- Kameleoon's public MCP server serves its documentation and cannot read your account, so any tool that claims to list your experiments through that server is showing you the wrong connection.
- The Automation API path needs credentials your team controls, so keep them in private settings and start with read access while the team builds trust in the flow.
- Code experiments can carry their real change in code the plan only names, so describe what the code changes in plain words before you lint, or the checker will score a plan that sounds emptier than the test really is.
- A passing score says the write-up covers what the rules ask for. It cannot say the idea is worth testing, that the traffic exists to reach a clear result, or that the change is safe to build, and those calls stay with your team.