@skyramp/mcp 0.0.59 → 0.0.60-rc.2

package/build/prompts/test-recommendation/test-recommendation-prompt.js

@@ -1,137 +1,199 @@
-/**
- * Test Recommendation Prompt
- * Prompt for generating actionable test recommendations
- */
-export function getTestRecommendationPrompt(mapping, analysis, topN = 7, analysisScope = "full_repo") {
+import { buildPrioritizationDimensions, buildTestExamples, buildTestPatternGuidelines, buildTestQualityCriteria, buildGenerationRules, buildToolWorkflows, buildCoverageChecklist, } from "./recommendationSections.js";
+function formatTestLocations(locs) {
+    const entries = Object.entries(locs || {});
+    if (entries.length === 0)
+        return "";
+    return "\n**Existing test files (do NOT duplicate these):**\n" +
+        entries.map(([type, files]) => "  - [" + type + "] " + files).join("\n");
+}
+export function buildRecommendationPrompt(analysis, analysisScope = "full_repo", focus = "all", topN = 10, prContext, workspaceAuthHeader) {
     const isDiffScope = analysisScope === "current_branch_diff";
     const diffContext = analysis.branchDiffContext;
-    // --- Build a compact summary of priority scores (no full JSON dump) ---
-    const topScores = mapping.priorityScores
-        .filter((s) => s.feasibility !== "not-applicable")
-        .slice(0, topN);
-    const scoreLines = topScores
-        .map((s) => {
-        const priority = s._finalScore >= 100 ? "high" : s._finalScore >= 70 ? "medium" : "low";
-        const avail = s.requiredArtifacts.available.join(", ") || "none";
-        const miss = s.requiredArtifacts.missing.join(", ") || "none";
-        return (`- **${s.testType.toUpperCase()}** | priority: ${priority} | feasibility: ${s.feasibility}\n` +
-            `  Reasoning: ${s.reasoning}\n` +
-            `  Artifacts available: ${avail} | missing: ${miss}`);
-    })
-        .join("\n");
-    // --- Build compact repo context (no full JSON dump) ---
-    const endpoints = analysis.apiEndpoints.endpoints
-        .slice(0, 30) // cap at 30 to keep size sane
-        .map((e) => `  ${e.method} ${e.path}${e.authRequired ? " [auth]" : ""}`)
+    const openApiSpec = analysis.artifacts?.openApiSpecs?.[0];
+    // ── Frontend / UI change detection ──
+    const FRONTEND_FILE_PATTERN = /\.(tsx?|jsx?|vue|svelte|css|scss|less|html)$/;
+    const API_DIR_PATTERN = /\/(api|routes?|controllers?|routers?|handlers?|endpoints?|server)\//;
+    const hasFrontendChanges = isDiffScope && diffContext
+        ? diffContext.changedFiles.some(f => FRONTEND_FILE_PATTERN.test(f) &&
+            !API_DIR_PATTERN.test(f) &&
+            /\/(components?|pages?|views?|layouts?|app|src\/app|frontend|client|public|styles?)\//i.test(f))
+        : false;
+    const hasApiChanges = isDiffScope && diffContext
+        ? (diffContext.newEndpoints.length > 0 || diffContext.modifiedEndpoints.length > 0)
+        : false;
+    const isUIOnlyPR = hasFrontendChanges && !hasApiChanges;
+    // ── Mode preamble ──
+    const modePreamble = isDiffScope
+        ? `You are in **PR mode**. Maximize test coverage for the branch changes.
+Focus on tests that validate the changed fields, endpoints, and their interactions.
+**CRITICAL**: Recommend MULTIPLE integration tests — at minimum one multi-resource workflow
+AND one CRUD lifecycle.
+${isUIOnlyPR ? `\n**UI-only PR.** Prioritize UI tests and E2E. Skip fuzz/contract.`
+            : hasFrontendChanges ? `\n**Mixed PR (frontend + API).** Integration > E2E > UI > fuzz/contract.`
+                : ``}
+Output should be concise and immediately actionable.`
+        : `You are in **Repo mode**. Comprehensive test strategy across all endpoints.`;
+    // ── Endpoint listing ──
+    const allEndpoints = analysis.apiEndpoints.endpoints;
+    const endpointLines = allEndpoints
+        .flatMap((ep) => (ep.methods ?? []).map((m) => `  ${m.method} ${ep.path}${m.authRequired ? " [auth]" : ""} (${(m.interactions ?? []).length} interactions)`))
         .join("\n");
+    const authMethod = analysis.authentication.method || "unknown";
+    const authHeaderValue = workspaceAuthHeader
+        ? workspaceAuthHeader
+        : /session|cookie|nextauth/i.test(authMethod) ? "Cookie"
+            : /api[_-]?key/i.test(authMethod) ? "X-API-Key"
+                : "Authorization";
     const repoContext = `
 Repository: ${analysis.metadata.repositoryName}
 Framework: ${analysis.projectClassification.primaryFramework} (${analysis.projectClassification.primaryLanguage})
 Project type: ${analysis.projectClassification.projectType}
-Auth: ${analysis.authentication.method}
+Auth: ${authMethod} (header: ${authHeaderValue})
 Base URL: ${analysis.apiEndpoints.baseUrl}
-Endpoints (${analysis.apiEndpoints.totalCount} total):
-${endpoints}
+Endpoints (${analysis.apiEndpoints.totalCount}):
+${endpointLines}
 `.trim();
-    // --- Branch diff context (only the essentials) ---
+    // ── Branch diff ──
     let diffSection = "";
     if (isDiffScope && diffContext) {
-        const newEps = diffContext.newEndpoints
-            .map((e) => `  ${e.method} ${e.path} (${e.sourceFile})`)
-            .join("\n") || "  none";
-        const modEps = diffContext.modifiedEndpoints
-            .map((e) => `  ${e.method} ${e.path} (${e.sourceFile})`)
-            .join("\n") || "  none";
+        const fmtEps = (eps, detail) => eps.flatMap((ep) => (ep.methods ?? []).map((m) => `  ${m.method} ${ep.path} (${detail(m)})`)).join("\n") || "  none";
         diffSection = `
 ## Branch Diff Context
 Branch: \`${diffContext.currentBranch}\` → base: \`${diffContext.baseBranch}\`
 Changed files: ${diffContext.changedFiles.join(", ")}
 New endpoints:
-${newEps}
+${fmtEps(diffContext.newEndpoints, (m) => `${m.sourceFile}, ${m.interactionCount} interactions`)}
 Modified endpoints:
-${modEps}
+${fmtEps(diffContext.modifiedEndpoints, (m) => `${m.sourceFile}, ${m.changeType}`)}
 Affected services: ${diffContext.affectedServices.join(", ") || "N/A"}
-Summary: ${diffContext?.summary ?? "N/A"}
 
-**CRITICAL**: Focus recommendations ONLY on tests that validate the branch changes above.
+**CRITICAL**: Focus on tests that validate these changes and how they interact with existing resources.
+`;
+    }
+    // ── Interactions ──
+    let interactionSection = "";
+    if (focus === "all" || focus === "interactions") {
+        const diffEndpointKeys = new Set();
+        if (isDiffScope && diffContext) {
+            for (const ep of [...(diffContext.newEndpoints || []), ...(diffContext.modifiedEndpoints || [])]) {
+                for (const m of (ep.methods ?? []))
+                    diffEndpointKeys.add(`${m.method} ${ep.path}`);
+            }
+        }
+        const summaryLines = allEndpoints
+            .flatMap((ep) => (ep.methods ?? []).flatMap((m) => (m.interactions ?? []).map((i) => `  ${m.method} ${ep.path} → ${i.response.statusCode} (${i.type}): ${i.description}`)))
+            .join("\n");
+        const detailEndpoints = isDiffScope
+            ? allEndpoints.filter((ep) => (ep.methods ?? []).some((m) => diffEndpointKeys.has(`${m.method} ${ep.path}`)))
+            : allEndpoints;
+        const detailBlocks = detailEndpoints
+            .flatMap((ep) => (ep.methods ?? []).flatMap((m) => (m.interactions ?? []).map((i) => {
+            const reqBody = i.request.body ? `\n    requestBody: ${JSON.stringify(i.request.body)}` : "";
+            const resBody = i.response.body ? `\n    responseBody: ${JSON.stringify(i.response.body)}` : "";
+            const headers = i.request.headers ? `\n    headers: ${JSON.stringify(i.request.headers)}` : "";
+            return `  ${m.method} ${ep.path} → ${i.response.statusCode} (${i.type}): ${i.description}${reqBody}${resBody}${headers}`;
+        })))
+            .join("\n");
+        interactionSection = `
+## Endpoint Interactions
+${summaryLines}
+
+### Detailed (request/response bodies)
+${isDiffScope ? "Changed endpoints only. " : ""}Use source code schemas (Zod/Pydantic/DTOs) for actual request bodies.
+${detailBlocks}
+`;
+    }
+    // ── Scenarios ──
+    let scenarioSection = "";
+    if (focus === "all" || focus === "scenarios") {
+        const scenarios = analysis.businessContext.draftedScenarios;
+        if (scenarios.length > 0) {
+            const baseUrl = analysis.apiEndpoints.baseUrl;
+            const scenarioBlocks = scenarios
+                .map((s) => {
+                const stepLines = s.steps.map((st) => `      ${st.order ?? ""}. **${st.method} ${st.path}** → ${st.expectedStatusCode ?? 200}: ${st.description || ""}`).join("\n");
+                const toolCalls = s.steps.map((st) => `      skyramp_scenario_test_generation({ scenarioName: "${s.scenarioName}", destination: "${s.scenarioName}", baseURL: "${baseUrl}", method: "${st.method}", path: "${st.path}", statusCode: ${st.expectedStatusCode ?? 200}, authHeader: "${authHeaderValue}", requestBody: <from source schemas for ${st.method} ${st.path}> })`).join("\n");
+                return (`  ### ${s.scenarioName} (${s.category}, ${s.priority})\n` +
+                    `  ${s.description}\n` +
+                    `  **Steps:**\n${stepLines}\n` +
+                    `  **Chaining keys:** ${s.chainingKeys.join(", ") || "none"}\n` +
+                    `  **Tool calls:**\n${toolCalls}\n` +
+                    `  Then: skyramp_integration_test_generation({ scenarioFile: "scenario_${s.scenarioName}.json", authHeader: "${authHeaderValue}" })`);
+            })
+                .join("\n\n");
+            scenarioSection = `
+## Drafted Scenarios — EACH = MANDATORY Integration Test
+**Base URL:** \`${baseUrl}\` | **Auth:** \`${authHeaderValue}\`
+
+Only use scenarios where resources are ACTUALLY related in the codebase. Replace any
+scenario that pairs unrelated resources with one reflecting real foreign key relationships.
+
+**Quality bar:** Realistic request bodies, actual foreign keys for chaining, response data
+verification (not just status codes), realistic test data (not "test product").
+**Path verification:** Cross-reference paths against Router Mounting context — use correct
+nested paths. **Request bodies:** Replace placeholders with actual schemas from source code.
+
+${scenarioBlocks}
+`;
+        }
+        else {
+            scenarioSection = `
+## Scenarios — Draft From Your Analysis
+
+Draft at least 2-3 MEANINGFUL scenarios based on your codebase analysis:
+1. **Cross-resource workflow** — resources referencing each other via foreign keys
+2. **Search/filter + verify** — create data, search, verify results
+3. **Error handling** — invalid cross-resource references → appropriate errors
+
+Use base URL: \`${analysis.apiEndpoints.baseUrl}\` and auth: \`${authHeaderValue}\`.
+`;
+        }
+    }
+    // ── PR History ──
+    let prHistorySection = "";
+    if (prContext && prContext.previousRecommendations.length > 0) {
+        const recLines = prContext.previousRecommendations
+            .map((r) => `  - [${r.status.toUpperCase()}] ${r.testType} — ${r.endpoint}${r.scenarioName ? ` (scenario: ${r.scenarioName})` : ""}`)
+            .join("\n");
+        prHistorySection = `
+## PR History (PR #${prContext.prNumber})
+${recLines}
+**Do NOT re-recommend tests already listed above.**
 `;
     }
+    // ── Compose all sections ──
     const scopeNote = isDiffScope
-        ? "Recommendations are scoped to the current branch changes only. All specific test suggestions MUST target the new/modified endpoints listed in the Branch Diff Context."
-        : "Recommendations cover the full repository.";
+        ? "Scoped to current branch changes."
+        : "Covers the full repository.";
     return `
-Generate actionable test recommendations based on the priority scores and repository analysis below.
+${modePreamble}
 
 Scope: ${scopeNote}
+
+${buildTestQualityCriteria()}
+
+${buildPrioritizationDimensions()}
+
+${buildTestExamples()}
+
+${buildTestPatternGuidelines()}
+
+${buildGenerationRules(isUIOnlyPR)}
+
 ${diffSection}
 ## Repository Context
 
 ${repoContext}
 
-## Prioritized Test Types (top ${topN})
-
-${scoreLines}
-
-## Priority Mapping Summary
-- High priority: ${mapping.summary.highPriority.join(", ") || "none"}
-- Medium priority: ${mapping.summary.mediumPriority.join(", ") || "none"}
-- Low priority: ${mapping.summary.lowPriority.join(", ") || "none"}
-
-## Your Task
-
-Generate specific, actionable test recommendations for the top ${topN} test types listed above.
-
-**MANDATORY RULES**:
-1. **NO numeric scores** in output — use only: "high", "medium", "low".
-2. **DO NOT mark any test "blocked"** even if artifacts are missing.
-3. **Branch scope**: All specific test suggestions MUST target endpoints/code that changed in the branch diff.
-4. **DO NOT create or save any files** — output everything inline in your response.
-
-## Output Structure
-
-Return a JSON object with this structure:
-
-\`\`\`json
-{
-  "summary": {
-    "totalRecommended": 3,
-    "highPriorityCount": 2,
-    "estimatedEffort": "4-6 hours for top 3 tests",
-    "quickWins": ["Smoke tests (OpenAPI available, 30 min)"]
-  },
-  "recommendations": [
-    {
-      "priority": "high",
-      "testType": "contract",
-      "rationale": "Why this is high priority (DO NOT mention numeric scores)",
-      "specificTests": [
-        {
-          "testName": "Order quantity validation contract test",
-          "description": "Verify POST /api/v1/orders rejects quantity < 1",
-          "targetEndpoint": "POST /api/v1/orders",
-          "targetFlow": "Order creation validation",
-          "requiredInputs": {
-            "available": [{"name": "openApiSpec", "path": "./openapi.json"}],
-            "missing": []
-          },
-          "estimatedValue": "High - catches regression in validation rule change"
-        }
-      ],
-      "gettingStarted": {
-        "prerequisites": ["Service running at localhost:8000"],
-        "quickStartCommand": "Use Skyramp MCP generate tools",
-        "documentationUrl": "https://www.skyramp.dev/docs"
-      }
-    }
-  ],
-  "nextSteps": [
-    "1. Start with highest priority test type",
-    "2. Use Skyramp MCP generate tools to create each test",
-    "3. Execute and validate results"
-  ]
-}
-\`\`\`
+${interactionSection}
+${scenarioSection}
+${prHistorySection}
+## Existing Tests
+- Frameworks: ${analysis.existingTests.frameworks.join(", ") || "none"}
+${formatTestLocations(analysis.existingTests.testLocations)}
+
+${buildToolWorkflows(authHeaderValue)}
 
-Generate recommendations now. Return the JSON object directly in your response text.
+${buildCoverageChecklist(openApiSpec, isUIOnlyPR, hasFrontendChanges, authHeaderValue, topN)}
 `;
 }

package/build/prompts/testGenerationPrompt.js

@@ -1,4 +1,3 @@
-// src/prompts/skyrampPrompt.ts
 import { logger } from "../utils/logger.js";
 export function registerTestGenerationPrompt(mcpServer) {
     logger.info("test generation prompt");
@@ -26,7 +25,7 @@ export function registerTestGenerationPrompt(mcpServer) {
 1. **Priority Scores Must Remain Unchanged**: When a test type is missing required inputs (e.g., Playwright recordings, traces), **DO NOT**:
    - Mark the test as "blocked" in the output
    - Adjust or reduce the priority score
-   - Exclude it from recommendations if it ranks in the top 7
+   - Exclude it from recommendations
 2. DO NOT CREATE ANY .json or .md file during repository analysis, test mapping, or test recommendation.
 
 **CONTRACT TEST:**
@@ -115,7 +114,7 @@ Let us generate a UI test with frontend playwright trace file skyramp_playwright
 
 **SCENARIO PARSING:**
 - Purpose: Parse natural language scenarios into structured JSON arrays of API requests
-- Requirements: A natural language scenario description, API schema (OpenAPI/Swagger file or URL)
+- Requirements: A natural language scenario description. API schema (OpenAPI/Swagger file or URL) is OPTIONAL — scenarios work without it using endpointURL and requestBody from source code
 - Features: Automatically breaks down any user-provided scenario into sequential API calls with request chaining
 - Output: Returns a JSON array where each element represents an API request with method, endpoint, parameters, and dependencies
 

package/build/prompts/testbot/testbot-prompts.js

@@ -9,99 +9,102 @@ function getTestbotPrompt(prTitle, prDescription, diffFile, testDirectory, summa
 <TEST DIRECTORY>${testDirectory}</TEST DIRECTORY>
 <REPOSITORY PATH>${repositoryPath}</REPOSITORY PATH>
 
-For all the following work, use the tools offered by Skyramp MCP server.
-
-Then perform ALL of the following tasks. Every task is MANDATORY — do NOT skip any task based on your own judgment unless the task itself gives you an explicit condition to skip.
-
-## Task 1: Recommend New Tests (MANDATORY — but skip if no application code changed)
-
-Read the diff at \`${diffFile}\`. Classify EVERY changed file using these categories:
-
-**Non-application files (DO NOT generate tests for these):**
-- CI/CD workflow files (.github/workflows/*.yml, .gitlab-ci.yml, Jenkinsfile, etc.)
-- Markdown documentation (.md files, README, CHANGELOG, CONTRIBUTING, etc.)
-- Dependency lock files (package-lock.json, yarn.lock, Pipfile.lock, poetry.lock, Gemfile.lock, go.sum, etc.)
-- Configuration-only files (.gitignore, .editorconfig, .prettierrc, renovate.json, dependabot.yml, etc.)
-- License files (LICENSE, NOTICE, etc.)
-
-**Application source code (generate tests for these):**
-- Routes, controllers, handlers, API endpoints
-- Models, schemas, validators, serializers, DTOs
-- Business logic, services, middleware, utilities
-- Test helpers and test fixtures
-- Any file with a source extension (.py, .ts, .js, .java, .go, .rb, .cs, .kt, .swift, etc.) that is NOT in the non-application list above
-
-**SKIP RULE — THIS IS MANDATORY:**
-If EVERY changed file in the diff falls into the "non-application files" category above, you MUST skip steps 1–6 entirely. Do NOT call \`skyramp_analyze_repository\`, do NOT call \`skyramp_map_tests\`, do NOT generate any tests. Instead, proceed directly to Task 2. In your report, state: "Task 1 skipped: PR contains only non-application changes (CI/docs/config)."
-
-**When in doubt:** If even ONE changed file looks like it could be application source code, run steps 1–6.
-
-1. Call \`skyramp_analyze_repository\` with:
-   - \`repositoryPath\`: "${repositoryPath}"
-   - \`analysisScope\`: "current_branch_diff"${baseBranch ? `\n   - \`baseBranch\`: "${baseBranch}"` : ''}
-2. MANDATORY: Call \`skyramp_map_tests\` with \`stateFile\` (the state file path returned above) and \`analysisScope: "current_branch_diff"\`.
-3. MANDATORY: Call \`skyramp_recommend_tests\` with the \`stateFile\` returned by \`skyramp_map_tests\`. Use the priority summary and the specific endpoints/files that changed to determine exactly what to test.
-4. Generate tests using the Skyramp MCP generate tools, in priority order (minimum 3 test types).
-5. Use Skyramp MCP to execute the generated tests and validate the results.
-6. **E2E / UI Test Generation from Trace Files**: Search the repository for existing Skyramp trace files that can be used for E2E or UI test generation. Look for:
-   - Backend trace files: files matching patterns like \`**/skyramp*trace*.json\`, \`**/skyramp-traces.json\`, or \`**/*trace*.json\` in test directories
-   - Playwright UI trace files: files matching patterns like \`**/skyramp*playwright*.zip\`, \`**/*playwright*.zip\`, or \`**/*ui*trace*.zip\`
-   Search in the test directory (\`${testDirectory}\`), the repository root, and any \`.skyramp/\` directories.
-   - If you find BOTH a backend trace file AND a Playwright trace ZIP, call \`skyramp_e2e_test_generation\` with both files to generate an E2E test.
-   - If you find ONLY a Playwright trace ZIP (no backend trace), call \`skyramp_ui_test_generation\` with the Playwright file to generate a UI test.
-   - When generating E2E/UI tests, use the same language and framework as other tests in the repository. Default to Python with pytest if no convention is detected.
-   - Execute any generated E2E/UI tests to validate them. Note: Playwright browsers are pre-installed in the CI environment.
-
-**IMPORTANT — Endpoint Renames:** If the diff shows an endpoint path was renamed (e.g. \`/products\` changed to \`/items\`) and existing tests already cover that endpoint under the old name, do NOT generate new tests for the renamed endpoint. The existing tests will be updated with the new path in Task 2 (Test Maintenance). Only generate new tests for genuinely new endpoints that have no existing test coverage under any name.
-
-## Task 2: Existing Test Maintenance (MANDATORY)
-
-You MUST always run the steps below. Do NOT skip this task based on your own assessment of whether tests exist or are relevant — use the tools to determine that.
-
-1. Call \`skyramp_discover_tests\` with \`repositoryPath\`: "${repositoryPath}" to find all existing Skyramp-generated tests.
-   You may skip the rest of this task ONLY if it explicitly returns zero Skyramp-generated tests.
-
-2. **Baseline — check for parallel CI first:**
-   a. Read the workflow files in \`.github/workflows/\` and check if any workflow (other than the Skyramp Testbot workflow) is triggered on \`pull_request\` AND runs tests against the test directory (look for commands like \`pytest\`, \`jest\`, \`npm test\`, \`go test\`, \`skyramp test\`, or similar test execution commands).
-   b. If such a workflow exists, run: \`gh run list --commit $(git rev-parse HEAD) --workflow <workflow-filename> --json status,conclusion --limit 1\` to check if it has completed for the current commit.
-   c. If the parallel workflow completed successfully — record beforeStatus as "Pass" for the discovered tests and note "baseline from CI workflow <workflow-name>" in beforeDetails. Skip to step 3.
-   d. If the parallel workflow completed with failure — record beforeStatus as "Fail" and capture the failure context in beforeDetails. Skip to step 3.
-   e. If no parallel test workflow exists, it hasn't completed yet, or the \`gh\` command fails for any reason (e.g. permissions, CLI not available) — execute ALL discovered tests AS-IS (before any modifications) using \`skyramp_execute_tests_batch\` or \`skyramp_execute_test\`. Record each test's status and details as the "before" results. In beforeDetails, describe the execution result (e.g. "Pass (10.8s)" or "Fail (404 Not Found)"). If you could not query CI, just note "unable to query existing CI pipeline" — do NOT expose internal details like authentication errors.
-
-3. Call \`skyramp_analyze_test_drift\` with the \`stateFile\` returned by \`skyramp_discover_tests\`.
-4. Call \`skyramp_calculate_health_scores\` with the \`stateFile\` from the previous step.
-5. Call \`skyramp_actions\` with the updated \`stateFile\`. This tool returns instructions describing what needs to change in each test file — it does NOT modify the files itself.
-6. **You MUST modify the existing test files in-place using your file editing tools.** Read the instructions from \`skyramp_actions\`, cross-reference with the code diff, and edit each test file directly.
-   - If \`skyramp_actions\` returns endpoint rename mappings (old path → new path), apply them as simple find-and-replace on the test file URLs. Do NOT regenerate or restructure the test — only update the paths.
-   - If \`skyramp_actions\` suggests file renames (e.g. \`products_smoke_test.py\` → \`items_smoke_test.py\`), rename the files using \`git mv\` after updating their content.
-   - The goal is to fix the discovered tests so they pass with the new code, preserving the original test structure and logic. Do NOT create new test files as a substitute for fixing existing ones.
-7. Execute the modified tests using Skyramp MCP and validate the results. This includes E2E and UI tests — Playwright browsers are pre-installed in the CI environment, so E2E/UI test execution is fully supported. Record each test's status and details as the "after" results.
-8. For each maintained test, report BOTH the before and after results in the \`testMaintenance\` array of the report (using the fileName, beforeStatus, beforeDetails, afterStatus, afterDetails fields), so the user has full visibility into whether the code change or the existing test was at fault.
-
-## Task 3: Submit Report (MANDATORY)
-
-After completing Tasks 1 and 2, you MUST call the Skyramp MCP tool "skyramp_submit_report" to submit your report.
-Pass '${summaryOutputFile}' as the summaryOutputFile parameter.
-
-For the commitMessage parameter, write a succinct summary (under 72 chars) of what you did, without any prefix. Examples:
-- "add contract tests for /products endpoint"
-- "update smoke tests for order API changes"
-- "add smoke and e2e tests for new /reviews endpoint"
-
-Do NOT write the report to a file yourself. Do NOT skip this step. The skyramp_submit_report tool is the ONLY way to submit the report.
-
-## Report Guidelines
-
-**businessCaseAnalysis:** Base this ONLY on facts from the PR title, description, and what the tools reported. If \`skyramp_analyze_repository\` reported 0 new endpoints, do NOT claim new endpoints were added — instead describe the change accurately (e.g. "frontend changes to consume existing API endpoints", "refactored service layer", "updated test configuration"). Never infer new backend endpoints from frontend fetch/API calls in the diff.
-
-When reporting test results, if you chose to skip executing a test, you MUST explain WHY you skipped it.
-NEVER use the phrase "CI timeout" or imply a timeout occurred unless a tool call actually timed out.
-Instead, set the status to "Skipped" and provide an honest reason in the details, for example:
-- "Skipped: no code changes affect this endpoint"
-- "Skipped: skyramp_discover_tests found no existing Skyramp tests"
-- "Skipped: only CI/config changes in this PR, no API changes"
-
-Reminder: Use the Skyramp MCP tools available to you for test analysis, generation, and execution.`;
+Use the Skyramp MCP server tools for all tasks below.
+
+## Task 1: Recommend & Generate New Tests
+
+Read the diff at \`${diffFile}\`. Skip Task 1 if all changed files are non-application
+(CI/CD, docs, lock files, config). Otherwise proceed:
+
+### Steps
+
+1. Call \`skyramp_analyze_repository\` with \`repositoryPath\`: "${repositoryPath}", \`analysisScope\`: "current_branch_diff"${baseBranch ? `\n   , \`baseBranch\`: "${baseBranch}"` : ''}
+2. Call \`skyramp_recommend_tests\` with the returned \`sessionId\`.
+   It returns 7 ranked recommendations. Generate the top 4, report the remaining 3
+   as \`additionalRecommendations\`.
+
+3. **Generate** at most 4 tests from the top 4 recommendations. Stop after 4.
+   Keep a list of every file the CLI creates (test files AND scenario JSON files).
+
+   **Frontend-only PRs** (no backend/API changes): only generate tests if relevant
+   Playwright traces exist. If no traces are available, skip generation entirely and
+   move all 7 recommendations to \`additionalRecommendations\` with scenario steps and
+   trace recording instructions. Do not generate integration tests for unchanged backend
+   APIs just to fill the quota — those tests don't validate the PR's changes.
+
+   **How to generate each type:**
+   - **Integration**: call \`skyramp_scenario_test_generation\` per step, then
+     \`skyramp_integration_test_generation\` with the scenario file.
+     The scenario JSON is written to the same \`outputDir\` as the test files
+     (e.g. \`tests/scenario_<name>.json\`), not \`.skyramp/\`.
+   - **Contract**: call \`skyramp_contract_test_generation\` with \`endpointURL\`, \`method\`,
+     and \`requestData\` for POST/PUT endpoints.
+     Pass \`apiSchema\` if an OpenAPI spec exists — it validates response structure.
+   - **Fuzz**: call \`skyramp_fuzz_test_generation\` with \`endpointURL\`, \`method\`, \`requestData\`.
+     Pass \`apiSchema\` if available — it generates smarter boundary values.
+   - **E2E/UI**: only generate when relevant Playwright traces exist (see step 5).
+     Without traces, move the test to \`additionalRecommendations\` with scenario steps
+     and trace recording instructions instead.
+   - Skip smoke tests entirely.
+
+   **Scenario quality:** Before generating, verify each step's preconditions are met by
+   prior steps. For example, you can't update a membership that was never created — check
+   the controller code for existence checks and ensure the scenario creates records first.
+
+   **Filenames:** Pass a descriptive \`--output\` name per test to avoid CLI overwrites.
+
+4. **Execute** the generated tests and record results.
+
+5. **Trace search** for E2E/UI: look in \`\${testDirectory}\`, repo root, and \`.skyramp/\` for
+   trace files (\`*trace*.json\`, \`*playwright*.zip\`). Only use a trace if it covers code
+   changed in this PR and targets localhost — skip traces for external hosts or unrelated code.
+
+   With relevant traces: backend + Playwright → \`skyramp_e2e_test_generation\`,
+   Playwright only → \`skyramp_ui_test_generation\`.
+
+**After generation, fix chaining only.** The CLI may use literal/hardcoded IDs instead
+of dynamic values from prior responses. Fix these two cases:
+1. **Path params:** variables like \`product_id = 'product_id'\` → use the response accessor
+   (e.g. \`getResponseValue(response, "response.id")\` in TS, \`skyramp.get_response_value(response, "id")\` in Python).
+2. **Request body refs:** hardcoded IDs in request bodies (e.g. \`"product_id": 1\`) → replace
+   with the dynamic ID extracted from the prior POST response (e.g. \`product_id\` variable or
+   \`dataOverride\`/\`data_override\` for the field).
+
+Change ONLY chaining-related values (path param assignments and body ID references).
+Preserve everything else exactly as the CLI generated it — headers, auth code, assertions,
+imports, and all other request body fields.
+
+## Task 2: Existing Test Maintenance
+
+Run this task regardless of Task 1 outcome — even if Task 1 was skipped or generated zero tests.
+
+1. Call \`skyramp_discover_tests\` with \`repositoryPath\`: "${repositoryPath}".
+2. If zero Skyramp tests found, report \`testMaintenance\` as an empty array with
+   a note in \`issuesFound\`: "No existing Skyramp tests found for maintenance."
+3. If tests exist:
+   a. Baseline them (from CI status or by executing).
+   b. Run \`skyramp_analyze_test_drift\` → \`skyramp_calculate_health_scores\` → \`skyramp_actions\`.
+   c. Apply actions (path renames, schema updates) in-place. Do not regenerate.
+   d. Execute modified tests. Report before/after in \`testMaintenance\`.
+
+## Task 3: Submit Report
+
+Verify Tasks 1 and 2 are complete, then call \`skyramp_submit_report\` with
+\`summaryOutputFile\`: "${summaryOutputFile}".
+
+\`commitMessage\`: under 72 chars, e.g. "add integration tests for /products and /orders"
+
+**newTestsCreated** — list every generated test file (at most 4):
+   \`testType\`, \`endpoint\`, \`fileName\`, \`description\`, \`scenarioFile\`, \`traceFile\`, \`frontendTrace\`
+   Use the actual file path returned by the generation tool for \`scenarioFile\`.
+   Include scenario JSON files in the git commit alongside test files.
+   Every test file in the commit should appear here. If you over-generated, delete extras first.
+   If no tests were generated (e.g. frontend-only PR without traces), pass an empty array.
+
+**additionalRecommendations** — remaining recommendations not generated:
+   \`testType\`, \`scenarioName\`, \`priority\`, \`description\`, \`steps\`, artifact paths
+
+**businessCaseAnalysis** — based only on PR data and tool outputs.`;
 }
 export function registerTestbotPrompt(server) {
     logger.info("Registering testbot prompt");