Playwright vs Selenium vs Cypress Decision Prompt

This prompt is for engineering leads, SDET architects, and QA managers who must choose between Playwright, Selenium, and Cypress for a specific project. The job-to-be-done is producing a structured, weighted recommendation grounded in your actual project constraints—not a generic feature list or popularity contest. Use it when you have concrete details about the application under test (SPA, SSR, mobile, desktop), team skills (JavaScript, TypeScript, Java, Python, C#), CI/CD environment (Docker, GitHub Actions, Jenkins, SaaS), browser requirements (Chromium, Firefox, WebKit, IE mode), and non-functional priorities (execution speed, debugging fidelity, cross-browser coverage, community support). The prompt forces the model to analyze trade-offs across these dimensions and produce a defensible decision matrix with explicit weights and rationale.

The ideal user brings project-specific context that constrains the decision space. Required inputs include: the application architecture type, the team's primary programming languages, the CI/CD platform and containerization strategy, the list of browsers that must be supported in automation, any organizational policies or existing tool investments, and the top three evaluation criteria ranked by importance. Without these inputs, the model will default to generic comparisons that fail to account for your operational reality. The prompt includes [CONSTRAINTS] and [CONTEXT] placeholders that force the model to ground its analysis in your provided details rather than retrieving memorized feature matrices. For high-stakes decisions where the chosen framework will anchor a multi-year automation strategy, pair this prompt with a human review step that validates the weighting logic and checks for missing constraints before finalizing the recommendation.

Do not use this prompt when the decision is already constrained by organizational mandates (e.g., 'we only use Selenium here'), when you lack project-specific details and are seeking general education, or when the real question is about tooling budget rather than technical fit. The prompt is also inappropriate for teams evaluating commercial codeless automation platforms, mobile-only testing frameworks like Appium, or API-only testing tools—it is scoped to browser-based UI automation frameworks. If your team has already selected a framework and needs implementation guidance, use the Manual Test to Playwright Script Conversion Prompt or the Selector Strategy and Fallback Generation Prompt instead. For teams evaluating automation ROI before framework selection, pair this prompt with the Test Automation ROI Evaluation Prompt to ensure the framework decision follows a build-vs-buy and automate-vs-manual analysis.

The prompt below is designed to be copied directly into your AI harness, IDE, or orchestration layer. It forces the model to act as a principal SDET evaluating three frameworks against your specific project constraints, not generic feature lists. Every square-bracket placeholder must be replaced with your project's concrete details before use. The prompt includes explicit instructions to ground every recommendation in the provided context and to flag any missing information that would change the comparison.

textCopy
You are a principal SDET with 15 years of experience selecting and implementing test automation frameworks across diverse project types. Your task is to produce a structured, evidence-grounded comparison of Playwright, Selenium, and Cypress for the specific project described below.

## PROJECT CONTEXT
[PROJECT_CONTEXT: Describe your application type, tech stack, team size, existing test infrastructure, CI/CD pipeline, browser requirements, and any regulatory or compliance constraints.]

## EVALUATION CRITERIA
[EVALUATION_CRITERIA: List the weighted criteria that matter for this decision, such as execution speed (weight: 0.25), cross-browser support (weight: 0.20), debugging capability (weight: 0.15), CI integration maturity (weight: 0.15), team skill alignment (weight: 0.15), and community support (weight: 0.10). Adjust weights and criteria to match your priorities.]

## CONSTRAINTS
[CONSTRAINTS: Specify any hard constraints such as must support Firefox ESR, must run in air-gapped environments, must integrate with TestRail, budget limits, or timeline pressures.]

## OUTPUT_SCHEMA
Produce a JSON object with the following structure:
{
  "comparison_matrix": [
    {
      "criterion": "string",
      "weight": number,
      "playwright_score": number (1-10),
      "selenium_score": number (1-10),
      "cypress_score": number (1-10),
      "evidence_for_scores": "string explaining the rationale with specific references to the project context"
    }
  ],
  "weighted_totals": {
    "playwright": number,
    "selenium": number,
    "cypress": number
  },
  "recommendation": {
    "primary_framework": "string",
    "rationale": "string explaining why this framework wins given the weighted scores and constraints",
    "risk_factors": ["string describing specific risks of this choice"],
    "mitigation_steps": ["string describing how to reduce each risk"]
  },
  "missing_information": ["string flagging any project details not provided that would materially change the recommendation"],
  "implementation_notes": {
    "estimated_ramp_up_weeks": number,
    "skill_gaps": ["string describing team skills that need development"],
    "ci_integration_steps": ["string describing concrete CI integration actions"]
  }
}

## RULES
1. Every score must reference specific project context details. Do not produce generic framework descriptions.
2. If the project context is insufficient to score a criterion, set the score to null and explain what information is missing in the "missing_information" array.
3. Do not recommend a framework that violates a hard constraint.
4. If two frameworks score within 0.5 weighted points of each other, explain the tie-breaking logic explicitly.
5. Flag any assumption you made about the project context that could be wrong.

After copying the template, replace each placeholder with your project's real data. The PROJECT_CONTEXT should be detailed enough that someone unfamiliar with your project could make an informed decision—include application architecture, existing test coverage, team composition, and any past automation failures. The EVALUATION_CRITERIA weights must sum to 1.0. If you cannot fill a placeholder because the information is unknown, leave it as a question in the prompt and the model will flag it in the missing_information output field. Before using this prompt in production, validate the output against the eval checks described in the Testing and Evaluation section of this playbook.

This prompt is typically used in a one-off analysis context by an engineering lead or architect evaluating test automation frameworks for a specific project. However, it can be integrated into a lightweight decision-support toolchain where multiple project contexts are evaluated over time. The primary integration points are input validation, output schema enforcement, and a human review gate before the recommendation is accepted. Because the prompt produces a weighted comparison matrix with project-specific constraints, the harness must ensure that the model does not return a generic, context-free recommendation that ignores the supplied project details.

To wire this prompt into an application, start by constructing the [PROJECT_CONTEXT] input from a structured form or project metadata store. Required fields include: application type (e.g., single-page app, multi-page app, mobile web), primary browsers under test, team programming language proficiency, CI/CD environment constraints, and any regulatory or compliance requirements that affect browser testing. Before calling the model, validate that all required fields are present and that the team skill profile includes at least one language relevant to the frameworks (JavaScript/TypeScript for Cypress and Playwright; Java, Python, C#, or JavaScript for Selenium). After receiving the model response, parse the output against a strict JSON schema that requires: a framework_scores object with numeric weights per criterion, a recommendation field with a single framework name, a rationale array of evidence-backed reasons, and a risks_and_mitigations array. If the response fails schema validation, retry once with the validation error appended to the prompt as a correction instruction. If the second attempt also fails, escalate for human review rather than silently accepting a malformed recommendation.

For model choice, use a capable reasoning model (such as Claude 3.5 Sonnet or GPT-4o) rather than a smaller or faster model, because the task requires weighing trade-offs across multiple dimensions and avoiding superficial pattern-matching to common online comparisons. Set the temperature low (0.0–0.2) to reduce variance in the scoring. Log every recommendation with the full input context, model response, and any human override for auditability. Do not cache this prompt aggressively, as project contexts and framework capabilities evolve. The most common failure mode in production is the model defaulting to a generic 'Playwright is modern and fast' recommendation without engaging with the specific constraints provided—your eval suite should include test cases where the correct answer is Selenium (e.g., legacy browser requirements) or Cypress (e.g., a team with deep Cypress experience and a single-page app) to verify the harness catches context-free responses.