FREE CLAUDE & CODEX PLUGIN TEMPLATE
A SOT-based PRD template for planning an experimentation and A/B testing system, covering hypotheses, variants, audience assignment, exposure tracking, primary metrics, guardrails, statistical review, and launch-or-stop decisions.
View source on GitHub · MIT licensed
USE CASE
Teams planning an experimentation platform for product, growth, and analytics practitioners who validate product hypotheses, plus platform operators responsible for reliable assignment and measurement.
CONTENTS
VIBESPEC VIEWER
Each screen is generated from the public SOT included with this template.
Open this screen in the live demo 
Open this screen in the live demo 
Open this screen in the live demo 
Open this screen in the live demo PRACTICAL GUIDE
This plan lets product, growth, and analytics teams evaluate a hypothesis with one connected record for experiments, variants, audiences, assignments, exposures, primary metrics, and guardrails. Platform operators investigate sample-ratio mismatch and delayed data; product owners use the reviewed evidence to launch, stop, or run a follow-up experiment. Review the HTML operating flow, then adapt the SOT JSON to your experimentation policy with VibeSpec in Claude or Codex.
For hypothesis, variant, audience, assignment rule, primary metric, and guardrail registration, define the required context, classification rules, and duplicate or missing-data checks before work enters the operating queue.
For experiment configuration, variant, assignment, exposure, primary-metric, guardrail, and result-history lookup, keep status, owner, priority, and change history together so the team can find the complete operating context.
In hypothesis review, experiment design, audience assignment, exposure monitoring, primary-metric and guardrail decisioning, and launch-or-stop handling, connect assignment, approval or rejection, exception handling, and completion confirmation as one accountable workflow.
Use experiment volume, assignment coverage, conversion impact, statistical confidence, guardrail breach, and decision reporting to track due dates, bottlenecks, exceptions, and completion outcomes by team, period, and operating category.
Set the role-based access, audit history, notifications, and external-system boundaries that Experimentation and A/B Testing Operations System needs to operate safely.
The download opens in a browser without setup. Compare the PRD, feature specification, screen structure, and user flow with the work your team does today.
Write down real user roles, required data, approval rules, exceptions, and success metrics. Start with the core flow from hypothesis, variant, audience, assignment rule, primary metric, and guardrail registration through hypothesis review, experiment design, audience assignment, exposure monitoring, primary-metric and guardrail decisioning, and launch-or-stop handling.
Attach the SOT JSON in Claude or Codex with the VibeSpec plugin and describe the change in plain language. VibeSpec keeps requirements, features, screens, and user flows connected.
Replace the template vocabulary, states, and classification with the terms your team uses. Keep hypothesis, variant, audience, assignment rule, primary metric, and guardrail registration and experiment configuration, variant, assignment, exposure, primary-metric, guardrail, and result-history lookup consistent.
Define who registers, reviews, approves, processes, and confirms completion, plus the conditions that trigger rejection or reprocessing in hypothesis review, experiment design, audience assignment, exposure monitoring, primary-metric and guardrail decisioning, and launch-or-stop handling.
Decide what experiment volume, assignment coverage, conversion impact, statistical confidence, guardrail breach, and decision reporting should measure, then connect any SSO, messaging, or adjacent-system integration to the related screens and user flow.
Add stable user assignment, mutual-exclusion groups, exposure retries, kill switches, and feature-flag handoffs as a separately scoped SDK integration.
Connect primary-metric and guardrail definitions to analytics events and the warehouse, including rules for delay, duplication, loss, and schema changes before decisioning.
Extend the plan with early-stopping rules, multiple-testing correction, experiment collisions, long-term holdouts, and portfolio-level learning and follow-up decisions.
Adapt this Experimentation and A/B Testing Operations System for our team. Ask about our user roles, states, required fields, and approval steps first, then update the requirements, screens, and user flows together.Reduce this Experimentation and A/B Testing Operations System to an MVP that keeps hypothesis, variant, audience, assignment rule, primary metric, and guardrail registration, experiment configuration, variant, assignment, exposure, primary-metric, guardrail, and result-history lookup, and hypothesis review, experiment design, audience assignment, exposure monitoring, primary-metric and guardrail decisioning, and launch-or-stop handling. Move automation and external integrations into separate initiatives.Use KPI Measurement Check as a measurement-readiness review for the experiment primary metric. Identify unresolved exposure denominator, decision window, sample-ratio-mismatch exclusion, and guardrail precedence. After asking the experiment owner for those decisions, write a scoped change plan limited to affected requirements, feature specs, screens, user flows, and event definitions.Yes. The complete HTML opens in a browser for review and sharing. To adapt the plan, attach the SOT JSON to Claude or Codex with the VibeSpec plugin and describe the change in plain language.
It includes hypothesis, variant, audience, assignment rule, primary metric, and guardrail registration, experiment configuration, variant, assignment, exposure, primary-metric, guardrail, and result-history lookup, hypothesis review, experiment design, audience assignment, exposure monitoring, primary-metric and guardrail decisioning, and launch-or-stop handling, and experiment volume, assignment coverage, conversion impact, statistical confidence, guardrail breach, and decision reporting, plus foundations for access, audit history, notifications, and integrations.
The HTML is a complete planning document for reading and sharing. The SOT JSON is source data that VibeSpec can update while keeping requirements, features, screens, and user flows connected.
No. KPI Measurement Check is a measurement-readiness review for whether primary metrics and guardrails have usable functions, events, and rules. It does not replace statistical analysis or the launch decision.
WORKFLOW