ab-test — Router

Language: Output always matches the language you write in (CLAUDE.md rule 7).

The entry point of the ab-test-playbook engine: parse the intent and route. First read ${CLAUDE_PLUGIN_ROOT}/CLAUDE.md: it is binding, and rule numbers below point there.

What "page shared" means

Defined once, here; ab-test-suggest, ab-test-design and the evals use it.

• A page is shared when the message carries the user's own page, screen or flow as a screenshot, a URL or a concrete description ("my pricing page has three plans, the middle one is highlighted, the button under each says …"). A bare page type ("my checkout") is not one. Shared → ab-test-design; not shared (a page type, a sector, a stage, or nothing) → ab-test-suggest, which also keeps a direct /ab-test-suggest call that shares a page.
• A screenshot is not a page when it shows something else: a results dashboard or a table of numbers is a results request (out of scope, below); a plan, brief or variant pair with a correctness question goes to ab-test-audit. Neither gets the problem question (rule 13).

Routing table

When the request isn't an A/B test

These checks come before the routing table; a trigger phrase in the same message doesn't override them.

• Diagnosis ("checkout dönüşümüm düştü, hangi testi yapmalıyım?"): a drop without a located step is located first, with the funnel or segment breakdown; design follows once the loss point is clear.
• Implementation or measurement ("how do I set up this event"): answer briefly, no scenario.
• A defect (a typo, a broken or inverted state, a dead link): a fix to ship, no test needed.
• A decision already made: one sentence on what a test would buy; don't push it.
• Poor fit (${CLAUDE_PLUGIN_ROOT}/knowledge/methodology.md → Where this playbook works well; tiers Suitable / Conditional / Poor fit, not the priority words): a low-volume enterprise page or a months-long cycle is said plainly, with the alternatives there. A Conditional context (a regulated pre-quote form, a subscription) is still tested, with that tier's care.

Ambiguous intent

suggest versus design is never ambiguous (above). A request fitting two other rows ("can you look at my cart page": design or audit?): with a page shared, rule 13's question covers it, option (d) split in two ("no specific problem, suggest tests" / "audit my existing plan or variant"); with no page, state both readings in one line and ask which. Never the same ambiguity twice in a session.

Front door: one question

A shared page gets only rule 13's multiple-choice question, worded for the page (a form → "isn't filling out the form", a product page → "isn't adding to cart"):

• Starts but doesn't finish (enters the flow, doesn't complete it)
• Never starts (sees the page, doesn't take the first action)
• Comes but low quality (volume, no quality)
• No specific problem (look at the page, tell me)

It holds the turn, is asked once for several screens, and not again in the session; no pick → (d); after the answer, a screen with no strong candidate gets one line. Traffic, test tool and budget are never asked (rule 5); a named tool only shapes the setup notes' vocabulary. A market question for payment, shipping, price display or trust signals (rule 11) waits its turn under rule 19 and is usually answered by the domain, currency or fields.

Never do

• Deliver anything but a complete record (rule 1), with exactly one primary KPI (rule 2), as a final card after both reviews (rule 17), never a draft.
• Regenerate the three boxes unasked, or dump the sub-skill machinery to the user.
• Compute, estimate or interpret a sample size, duration, significance or winner (rule 5).
• Present an archive scenario as generated, or as a tested win (rule 8).