Ready-to-use prompt templates for the Convert MCP server, organized by workflow. Derived from real-world usage by Hype Digital (strategy & analysis) and Optiphoenix (developer workflows).
[brackets] with your actual values.
reporting, readOnly, or all.
These templates support the "learning system" workflow described by Hype Digital — shifting from isolated test reporting to compounding strategic insight.
Monthly or quarterly reviews. Getting a high-level picture of what's been running, what's concluded, and what the outcomes were.
After a batch of tests has concluded. Looking for recurring themes in what works and what doesn't.
Extracting learning from tests that didn't win. This is where most CRO programs leave value on the table.
Understanding whether test results vary by audience segment. Critical for determining if a "winner" is actually universal or segment-specific.
Periodic review to assess whether your team is generating good hypotheses, based on actual test outcomes.
When a site redesign, replatform, or major feature launch has occurred and you want to compare experiment performance on either side of that event.
Weekly check-in to ensure running experiments are healthy and on track.
These templates support the Optiphoenix workflow — building, configuring, and deploying experiments via the MCP server from within an IDE.
Pushing a fully coded experiment into Convert after development is complete.
Before setting up a new experiment — checking what goals and audiences already exist in the project so you can reference them by ID.
Modifying a draft or paused experiment — e.g., adjusting traffic split, swapping variation code, or changing goals.
During QA, verifying that experiments are configured correctly before going live.
Pulling back the JS/CSS that was pushed to Convert, for code review or to sync back to the local repo.
Routine maintenance — stopping experiments that have run too long without results or are showing harmful trends.
Useful for anyone — strategists, developers, and managers alike.
Anytime you have a "how do I..." question about Convert. The MCP server's built-in knowledge base (5,279+ indexed documentation chunks) can answer without leaving the conversation.
Reporting to leadership on the team's experimentation pace and productivity.
Onboarding onto a new account or project. Getting a complete picture of what exists.
Before competitive analysis. Pulling your own experiment data to compare against industry benchmarks.
If you're using Cursor, paste this into a .cursorrules file at your workspace root to standardize how the AI builds Convert experiments. Adapted from the Optiphoenix workflow.
## A/B Test Automation: General Workflow and Standards
### Inputs the AI must collect from the user
- **Experiment name**: UPPERCASE with underscores (e.g., `MT_01`, `UL_65`)
- **Test brief**: What needs to be changed and why
- **Control HTML**: Pasted markup or a URL to fetch and parse
- **Key selectors (optional)**: Prefer these if provided; otherwise derive from control HTML
### Output directory structure
EXPERIMENT_NAME/
├── src/
│ ├── config.js # Selectors, html, text, styles
│ ├── utils/ # Shared utilities (optional)
│ └── v1/
│ ├── v1.js # Main experiment logic
│ └── v1.css # Styles
└── dist/ # Compiled output (optional)
### Coding standards
- **Naming:** Experiments: UPPER_CASE. CSS classes: lowercase with experiment prefix. Functions/variables: camelCase.
- **JavaScript:** Use const/let (never var). Arrow functions where suitable. querySelector/querySelectorAll for DOM. insertAdjacentHTML or insertAdjacentElement (never innerHTML or createElement).
- **Styles:** Class-based (no inline). Media queries for responsiveness. Body class scoped to experiment name.
### Automation flow
1. Collect inputs (experiment name, brief, control HTML, selectors)
2. Parse control HTML → identify targets → derive selectors if missing
3. Create folder structure and boilerplate files
4. Implement variation logic in src/v1/v1.js
5. Add styles in src/v1/v1.css
6. Build into dist/ (optional)
7. Summarize changes and next steps for QA
### Convert MCP deployment
After code review and QA, use the Convert MCP to:
1. List available goals, audiences, and locations for the target project
2. Create the experiment with the approved JS/CSS as variation code
3. Verify the configuration matches the local codebase
All templates assume the Convert MCP server is running and authenticated. See setup guide.
Templates marked all require write access. Start with reporting and escalate only when needed.
For best results, use models with strong agentic capabilities (Claude Sonnet 4.5+, GPT-5+) with extended thinking enabled.
These templates are starting points. Customize the placeholders, combine templates, and iterate based on your team's workflow.