Prompt Packs

Copy-paste prompts for QA Lead, SDET, and PM personas — plus a single one-shot demo prompt that walks the full MCP story.

For the full interactive version, see Prompt Packs and Web AI Assistant in the MCP docs. Last updated June 2026 · MCP @testneo/mcp-server@0.2.0 (68 tools) · prompts C17–C25, EM1–EM9.

New team / new web project (minimal UI)

Goal: get a project_id and Environment management rows (staging, {{base_url}}, optional login vars). See Quickstart — Section 4 and Customer E2E playbook Part B.

1. Dry run — set TESTNEO_MCP_ALLOW_WRITE=true and restart MCP (dry-run previews need writes enabled). Run testneo_bootstrap_web_mcp_project or testneo_create_web_project with confirm=false. Inspect preview.create_project.body (bootstrap) or would_post.body (create project).
2. Create — same tool with confirm=true, optional idempotency_key. If env rows are missing, use testneo_create_web_project_environment — API compatibility.
3. (Optional — Web AI) With a valid project_id, call testneo_ai_assistant_query project-wide or with context_name_query after testneo_list_unified_contexts — see Customer playbook Part B5.
4. Continue — Figma: testneo_figma_to_tests_workflow; Swagger (web): testneo_swagger_upload_and_generate with confirm=true; then testneo_run_generated_test_pipeline.

One-liner:

Run testneo_bootstrap_web_mcp_project with name "MCP Demo Site", website_url "https://your-app.example", confirm=false; verify preview.create_project.body (create_default_environment, initial_environment). If OK, run again with confirm=true and idempotency_key "bootstrap-demo-1". Summarize project_id and environment; if no env row, call testneo_create_web_project_environment with base_url (and username/password with is_secret true on password if needed).

QA Lead — quality signal, release risk, reruns

1) Connection sanity check

Validate my TestNeo MCP connection and list my projects with test case counts.

2) 30-day pulse

For project <PROJECT_ID>, show pass/fail trend for the last 30 days using a reasonable execution sample size, and summarize whether quality is stable, improving, or degrading in one short paragraph.

3) One-command QA intelligence

Call testneo_run_agent_workflow with workflow_type "qa_intelligence_workflow", project_id <PROJECT_ID>, range "30d", top_failures 2, rerun_limit 3. Summarize recurring_themes and triage_bundles, cite latest_failed_execution_ids, and list the top 3 follow-up actions for my team.

4) Failure triage sprint

Call testneo_run_agent_workflow with workflow_type "triage_failure_workflow", project_id <PROJECT_ID>, range "30d", top_failures 3. For each triage_bundles entry, give me: symptom, inferred theme, and concrete next QA steps.

5) Rerun decision (preview-first)

Call testneo_run_agent_workflow with workflow_type "rerun_decision_workflow", project_id <PROJECT_ID>, range "30d". Do not execute reruns — explain rerun_plan_preview and what would change with TESTNEO_MCP_ALLOW_WRITE and confirm=true on testneo_rerun_failed.

6) Semantic failure search

Search failures in project <PROJECT_ID> for "<KEYWORDS>" (e.g. checkout, login, timeout). Summarize recurring patterns and which areas need regression focus.

7) Deep dive on one run

Fetch execution summary and failure bundle for execution <EXECUTION_ID>. Explain in QA terms what broke, severity, and whether this looks like product bug vs test flake.

8) Human-in-loop after a fix

Pull execution logs for execution <EXECUTION_ID>. Recommend whether we should rerun the same test case, update NLP steps, or file a defect — and say what evidence supports that.

9) Find the right unified context fast

List unified contexts for project <PROJECT_ID>, then resolve by name_query "figma <feature>" so I get a definitive context_id for generation (matches Figma-ingested names like "Figma — Checkout flow"; use prefer_context_id if two rows collide).

10) Project route map governance

Show project route map for <PROJECT_ID> (testneo_get_project_route_map). If missing/partial, propose a merge payload for testneo_set_project_route_map with phrases we repeatedly use in failures. Do not apply unless I confirm=true.

SDET — automation, specs, flaky runs, MCP mechanics

1) Project + execution discovery

Validate TestNeo connection, list projects, then list recent failed executions for project <PROJECT_ID> with a short note on status normalization if anything looks ambiguous.

2) Structured watch

Watch execution <EXECUTION_ID> until completion (use polling). When done, summarize final status and any failure signals worth capturing in a CI ticket.

3) Failure bundle for automation

Get failure bundle for execution <EXECUTION_ID> and extract: failed steps, log snippets theme, inferred root cause bucket, suggested automation fixes (selectors, waits, data).

4) NLP hardening — routes

Using testneo_apply_route_hardening, show how these NLP Navigate lines rewrite with our server's route profile and map (or suggest TESTNEO_ROUTE_MAP_JSON entries if phrases are unknown): [paste commands].

5) Persist improved NLP

Update test case <TEST_CASE_ID> NLP commands to: [paste list]. Apply route hardening with apply_route_hardening=true before saving unless I already used explicit {{base_url}} paths everywhere. Confirm the payload you will send matches my intent.

6) Playwright SDK path

Export test case <TEST_CASE_ID> as Playwright SDK TypeScript spec, then review it for brittle steps. If MCP write is enabled and I approve, run Playwright spec preview for project <PROJECT_ID> with a clear test name and confirm=true — and watch the resulting execution.

7) Context-driven generation + preview

For project <PROJECT_ID>: resolve unified context by name_query "<LABEL_FRAGMENT>" (or list contexts first), then generate tests from the resolved context_id with auth_preamble preset saucedemo when relevant. Preview the first few cases as NLP + spec drafts; flag risk_flags like missing assertions. Note any route hardening changes.

8) Trend + flaky classification

For project <PROJECT_ID>, get pass_fail_trend plus recent failures list. Identify tests or flows that failed more than once in the window and label each as suspected flake vs probable defect based on MCP evidence only.

9) Greenfield web project + environment (zero UI)

With TESTNEO_MCP_ALLOW_WRITE=true: run testneo_bootstrap_web_mcp_project with name "<NAME>", website_url "<HTTPS_URL>", confirm=false — quote preview.create_project.body.create_default_environment and whether initial_environment is present. Then confirm=true with a fresh idempotency_key. If environment is null or the product has no Environment row, dry-run then create testneo_create_web_project_environment for project_id <ID> with variables [{"variable_name":"base_url","variable_value":"<HTTPS_URL>"}] and secrets as needed.

10) Tag discovery before CI batch

For project <PROJECT_ID>, call testneo_list_tests_by_tags with tags ["smoke", "@regression"], tag_match "any". If I confirm batch execution, call testneo_run_batch_by_tags with the same project and tags, confirm true, parallel false, and idempotency_key "sdet-tag-batch-1". Summarize routing and monitor_hint.

PM / engineering manager — plain language, outcomes, timelines

These prompts assume read-only MCP by default — usually enough for status and narratives.

1) Single project heartbeat

In plain language for a PM audience: summarize current quality status for project <PROJECT_ID> using recent executions and any trend MCP exposes. No tool jargon in the summary — explain what "good" vs "risky" means for release.

2) Weekly quality narrative

Give me a 5-bullet executive update for project <PROJECT_ID> covering pass rate trajectory, notable failures, customer-facing risk areas, and what we validated recently. Pull data via MCP tools, then simplify terminology.

3) "What broke recently?"

What failed in project <PROJECT_ID> in roughly the last two weeks at a glance? Describe impact in feature terms (e.g. checkout) not MCP tool names; include links or IDs execs rarely need — but keep execution IDs footnoted for engineering.

4) Trend direction

Is automated quality trending up or down for project <PROJECT_ID> over <RANGE e.g. 30d>? One chart-like sentence + one caveat about sample size based on MCP data.

5) Risk before demo or launch

We have a stakeholder demo soon. Scan project <PROJECT_ID> for recent failures and tell me top 3 product areas I should verbally caveat or avoid demoing — the risk list only, no blame.

6) Regression focus for planning

From MCP failure search/triage on project <PROJECT_ID>, what themes should roadmap planning prioritize next sprint (stability vs new feature risk)? Bullet list with business framing.

7) Human-in-loop design → tests (high level)

Someone ingested design context earlier. Explain at a PM level how project <PROJECT_ID> can go from Figma/unified context to draft tests — and what approvals are still required before auto-execution is safe. Actual IDs optional; keep it procedural.

8) Incident-style postmortem stub

For execution <EXECUTION_ID>, write a lightweight postmortem: what broke, scope, mitigation, prevention — readable by PM and ENG. MCP can provide technical detail; strip acronyms in the narrative.

One-shot "full demo" prompt

Use once to show someone the full MCP story (read-heavy by default). After it runs, you can selectively enable writes and rerun with approvals.

You are demonstrating the TestNeo MCP integration.

1) Validate the TestNeo connection and list projects; pick project <PROJECT_ID> (or ask me if unclear).

2) Optional: call testneo_ai_assistant_query once with that project_id — first a project-wide query on overall test health (response_style concise), then if unified contexts exist run testneo_list_unified_contexts and ask one context-scoped question using context_name_query (response_style detailed). Keep the AI assistant step under 10 lines of summary total.

3) For that project, call testneo_run_agent_workflow with workflow_type "qa_intelligence_workflow", project_id <PROJECT_ID>, range "30d", top_failures 2, rerun_limit 3: summarize execution_summary / pass rate, cite example failed execution IDs briefly, summarize recurring_themes from triage_bundles, and present rerun_plan_preview (do not execute reruns unless I explicitly confirm and writes are enabled).

4) Optionally, for test generation from a Figma (or other) unified context: call testneo_list_unified_contexts, then testneo_get_unified_context_by_name with a fragment of the context display name (e.g. name_query "figma checkout" for a context like "Figma — Checkout flow"). Outline generate from resolved_context_id → preview NLP + Playwright drafts, mention route hardening/env maps in one sentence if Navigate steps look vague, and list approvals needed before testneo_execute_generated_test_case with confirm=true.

5) Optionally, for tag-based regression: call testneo_list_tests_by_tags on the same project with tags I provide (e.g. ["smoke"]) and tag_match "any"; summarize matches. Do not call testneo_run_batch_by_tags unless I explicitly ask and writes are enabled.

6) End with three concrete prompts I can reuse next—one for QA lead, one for SDET, one for PM—all customized to real IDs and context names discovered in steps 1–4.
Keep the transcript tight: bullets and short prose, no fluff.

Engineering Memory (Jira / CSV → PR matches)

Historical bugs feed live PR matching — not by PR number, but by changed files and impact areas. Phase A: Jira sync runs automatically before validate (default ON).

EM1 — Validate PR with Jira memory (developer — default)

Detect git context (git rev-parse HEAD, git merge-base HEAD origin/main, git diff --name-status, git remote get-url origin).

Call testneo_pr_validation_workflow with project_id <PROJECT_ID>, repository, pull_request.number <PR_NUMBER>, git context, sync_jira_before_validate true, execution.run_impacted_tests true, confirm false.

Display the Release Brief. Highlight Jira sync + Historical Incident Matches. Explain: matches are by file/area overlap — not Jira issue → PR number.

EM2 — Bug CSV + validate (one call)

Call testneo_pr_validation_workflow with project_id <PROJECT_ID>, repository, pull_request, git, engineering_memory_csv_path "bugs/orders_incidents.csv", confirm false.
Summarize CSV ingest + memory matches in the Release Brief.

EM3 — Sync Jira + list memory (QA setup)

Call testneo_sync_engineering_memory with project_id <PROJECT_ID>, max_issues 50, lookback_days 90.
Call testneo_list_engineering_memory with project_id <PROJECT_ID>, limit 20.
Report entries by impact area; flag empty areas (use Jira labels on team-managed projects).

EM4 — Memory lookup without full validation

Call testneo_get_incident_matches with project_id <PROJECT_ID>, changed_files ["app/services/order_service.py", "app/models/order.py"], lookback_days 90.
Summarize match_score, match_tier, top matches with source (bug_csv / jira), pattern_id, source_mix_narrative, and recommended fix from top_resolution.

EM5 — Full ship loop with outcome learning (QA lead / EM)

Call testneo_create_release_bundle with project_id <PROJECT_ID>, release_name "<VERSION>", workflow_ids [<WORKFLOW_IDS>].
Call testneo_evaluate_release_gate with bundle_id "<BUNDLE_ID>", policy "both", min_confidence 85.
Call testneo_get_release_outcomes with project_id <PROJECT_ID>.
After deploy, call testneo_record_release_outcome with outcome_id "<OUTCOME_ID>", rollback <true|false>, incident_within_7d <true|false>.
Call testneo_get_release_calibration with project_id <PROJECT_ID> — leadership summary (read-only).

EM6 — Patterns and trend (before sprint planning)

Call testneo_refresh_engineering_memory_patterns with project_id <PROJECT_ID>.
Call testneo_list_engineering_memory_patterns with project_id <PROJECT_ID>.
List worsening patterns with source_mix_narrative and best_resolution.

EM7 — Pattern drill-down (from PR match)

Call testneo_list_engineering_memory_patterns with project_id <PROJECT_ID>, pattern_id <PATTERN_ID>.
Call testneo_list_engineering_memory with project_id <PROJECT_ID>, pattern_id <PATTERN_ID>.
Summarize contributing entries by source (jira, bug_csv, postmortem_upload).

EM8 — Calibration review (monthly release retro)

Call testneo_get_release_outcomes with project_id <PROJECT_ID>, limit 30.
Call testneo_get_release_calibration with project_id <PROJECT_ID>.
Summarize sample size and rollback correlation — advisory only.

PR Validation & Release Confidence

Seven PR tools + Engineering Memory. Works in Cursor, VS Code + Copilot, Windsurf, Claude Code, Cline, and any MCP client. Jira → memory sync is Step 0a by default.

PV1 — Validate my PR before I merge (developer, read-only)

Detect my git context:
  git rev-parse HEAD                                             → head_sha
  git merge-base HEAD origin/main 2>/dev/null || git merge-base HEAD origin/master → base_sha
  git diff --name-status <base_sha> HEAD                        → changed files ({ path, status })
  git remote get-url origin                                      → owner/name

Call testneo_pr_validation_workflow with project_id <PROJECT_ID>, repository.owner + repository.name (parsed from git remote), pull_request.number <PR_NUMBER> (ask me if unknown), git.base_sha, git.head_sha, git.changed_files as array of { path, status }, sync_jira_before_validate true, execution.run_impacted_tests true, confirm false.

Display the full Release Brief exactly as returned (includes Jira sync when connected).

PV3 — Explain what is blocking my merge (developer, follow-up)

Call testneo_explain_failure with workflow_id "<WORKFLOW_ID_FROM_BRIEF>", include_rerun_plan true.

For each blocking finding show: root cause in plain English, historical signal (failure_rate_7d, flakiness_score), changed files, exact test IDs to rerun, numbered next steps.

PV4 — Give me a prioritised fix plan (developer, follow-up)

Call testneo_suggest_fix with workflow_id "<WORKFLOW_ID_FROM_BRIEF>", priority_filter "all".

Show: NOW fixes (blocking — files, what to change, test IDs); NEXT fixes (warnings, safe to defer); Rerun strategy (which tool, which test IDs, how to re-validate).

PV6 — Release gate: PR risk sweep (QA lead)

Call testneo_get_pr_validation_history with project_id <PROJECT_ID>, limit 20.
Call testneo_run_agent_workflow with workflow_type "qa_intelligence_workflow", project_id <PROJECT_ID>, range "7d", top_failures 3, rerun_limit 3.

Cross-reference: which flows appear in BOTH PR validation blocking findings AND execution failure themes? Present as a table: flow | PR blocking count | execution failures | combined risk. End with go/hold/go-with-conditions.

PV8 — Is it safe to ship? (PM / engineering manager)

Call testneo_get_pr_validation_history with project_id <PROJECT_ID>, limit 15.

In plain language (no test IDs): (1) PASS/WARN/BLOCK distribution for recent PRs, (2) any BLOCK-level merges this week and the common risk factor, (3) low/medium/high release risk assessment, (4) one-sentence go/hold/go-with-conditions with the specific condition.

PV9 — Pre-flight risk check before coding (SDET / developer)

Call testneo_get_risk_signals with project_id <PROJECT_ID>, test_ids [<IDS_COVERING_FILES_YOU_PLAN_TO_CHANGE>].
Call testneo_get_pr_validation_history with project_id <PROJECT_ID>, limit 10.

Report: (1) tests with failure_rate_7d > 20% or flakiness_score > 30%, (2) whether these flows caused BLOCK-level validations before, (3) pre-coding risk summary — where to add extra assertions and what to monitor after your change.

C17 — Validate → explain → fix (developer one-shot)

Step 1: Auto-detect git context (terminal: git rev-parse HEAD, git merge-base HEAD origin/main, git diff --name-status, git remote get-url origin).

Step 2: Call testneo_pr_validation_workflow with project_id <PROJECT_ID>, parsed repository, pull_request.number <PR_NUMBER>, git context, sync_jira_before_validate true, execution.run_impacted_tests true, confirm false. Display the Release Brief (Jira sync runs in Step 0a).

Step 3: If blocking_count > 0, automatically call:
  testneo_explain_failure workflow_id <from brief> include_rerun_plan true
  testneo_suggest_fix workflow_id <from brief> priority_filter "now"
Present all three outputs together. Start with the risk level badge and merge recommendation.

C18 — PR history + QA intelligence cross-reference (QA lead)

Call testneo_get_pr_validation_history with project_id <PROJECT_ID>, limit 15.
Call testneo_run_agent_workflow with workflow_type "qa_intelligence_workflow", project_id <PROJECT_ID>, range "7d", top_failures 3, rerun_limit 3.

Cross-reference: which flows appear in BOTH PR blocking findings AND execution failure themes?
Present: (1) PR risk distribution this week, (2) top execution failure themes, (3) shared risk flows table, (4) go/hold/go-with-conditions recommendation with evidence.

C19 — PR pre-flight risk check (before coding)

Call testneo_get_risk_signals with project_id <PROJECT_ID>, test_ids [<IDS_COVERING_FILES_YOU_PLAN_TO_CHANGE>].
Call testneo_get_pr_validation_history with project_id <PROJECT_ID>, limit 10.

Report: (1) tests with failure_rate_7d > 20% or flakiness_score > 30%, (2) whether these flows caused BLOCK-level validations, (3) pre-coding risk summary.

C20 — Release confidence report (PM / engineering manager)

Call testneo_get_pr_validation_history with project_id <PROJECT_ID>, limit 20.
Call testneo_run_agent_workflow with workflow_type "qa_intelligence_workflow", project_id <PROJECT_ID>, range "30d", top_failures 3, rerun_limit 3.

Release confidence brief (max 250 words, no test IDs in prose):
  1. PR validation posture — PASS/WARN/BLOCK trend over recent PRs
  2. Execution quality — pass rate and top failure themes
  3. Top 3 shared risk areas (overlap of PR findings + execution failures)
  4. go/hold/go-with-conditions recommendation with specific condition

C21 — Full PR lifecycle: validate → explain → fix → re-validate

Step 1 — Planning (confirm false): detect git context and call testneo_pr_validation_workflow with project_id <PROJECT_ID>, pull_request.number <PR_NUMBER>. Display Release Brief.

Step 2 — Execution (on my explicit confirmation): call testneo_pr_validation_workflow with confirm true and execution.run_impacted_tests true.

Step 3 — Root cause: call testneo_explain_failure with workflow_id <from step 1 or 2>, include_rerun_plan true.

Step 4 — Fix plan: call testneo_suggest_fix with workflow_id <from step 1 or 2>, priority_filter "all".

Step 5 — After I push fixes with a new head_sha: call testneo_validate_pr with the same owner/name/pr_number/project_id and the new head_sha. Compare risk_score and risk_level before vs after; call out resolved vs remaining findings.

Where to learn more

• At a glance: one journey (interactive Prompt Packs)
• Web AI Assistant & prompt library
• Quickstart
• Customer E2E playbook (install → context / Swagger → run → triage)
• Workflows
• Tool Reference
• Unified Contexts