@skyramp/mcp 0.0.61 → 0.0.62

package/build/index.js

@@ -19,8 +19,8 @@ import { registerLoginTool } from "./tools/auth/loginTool.js";
 import { registerLogoutTool } from "./tools/auth/logoutTool.js";
 import { registerFixErrorTool } from "./tools/fixErrorTool.js";
 import { registerAnalyzeRepositoryTool } from "./tools/test-recommendation/analyzeRepositoryTool.js";
-import { registerMapTestsTool } from "./tools/test-recommendation/mapTestsTool.js";
 import { registerRecommendTestsTool } from "./tools/test-recommendation/recommendTestsTool.js";
+import { registerRecommendTestsPrompt } from "./prompts/test-recommendation/registerRecommendTestsPrompt.js";
 import { registerModularizationTool } from "./tools/code-refactor/modularizationTool.js";
 import { registerCodeReuseTool } from "./tools/code-refactor/codeReuseTool.js";
 import { registerScenarioTestTool } from "./tools/generate-tests/generateScenarioRestTool.js";
@@ -34,6 +34,7 @@ import { registerTestbotPrompt, registerTestbotResource, } from "./prompts/testb
 import { registerInitTestbotTool } from "./tools/initTestbotTool.js";
 import { registerSubmitReportTool } from "./tools/submitReportTool.js";
 import { registerInitializeWorkspaceTool } from "./tools/workspace/initializeWorkspaceTool.js";
+import { registerAnalysisResources } from "./resources/analysisResources.js";
 import { AnalyticsService } from "./services/AnalyticsService.js";
 import { initCheck } from "./utils/initAgent.js";
 const server = new McpServer({
@@ -47,13 +48,32 @@ const server = new McpServer({
         prompts: {
             listChanged: true,
         },
+        resources: {
+            listChanged: true,
+        },
     },
-    instructions: `Skyramp MCP Server — generates and executes API tests (smoke, fuzz, contract, load, integration, E2E, UI).
+    instructions: `Skyramp MCP Server — generates and executes API tests (fuzz, contract, integration, E2E, UI).
 
 ## Rules
 - NEVER show CLI commands. ALWAYS use the MCP tools provided.
 - For UI and E2E tests, use the trace collection start/stop tools.
 
+## Test Recommendation Flow (2-step)
+1. Call \`skyramp_analyze_repository\` → returns a \`sessionId\`.
+   The analysis scans source code (code-first) to build enriched endpoints
+   (Path → Method → Interaction with request/response bodies, headers, cookies)
+   and draft user-flow scenarios for integration/E2E tests.
+2. Call \`skyramp_recommend_tests\` with \`sessionId\` → the LLM reasons over the
+   enriched data to recommend tests, referencing specific interactions and scenarios.
+
+After analysis, you can also inspect data via MCP Resources:
+- \`skyramp://analysis/{sessionId}/summary\` — high-level overview
+- \`skyramp://analysis/{sessionId}/endpoints\` — compact endpoint listing
+- \`skyramp://analysis/{sessionId}/endpoints/{path}\` — full path detail
+- \`skyramp://analysis/{sessionId}/endpoints/{path}/{method}\` — single method detail
+- \`skyramp://analysis/{sessionId}/scenarios\` — drafted scenarios
+- \`skyramp://analysis/{sessionId}/diff\` — branch diff context
+
 ## Workspace Initialization (before ANY other Skyramp tool)
 Follow this flow EVERY time before calling any Skyramp tool:
 
@@ -78,16 +98,23 @@ Before calling ANY test generation tool, you MUST follow this flow:
 2. **Extract** the \`language\`, \`framework\`, \`outputDir\`, and \`api.baseUrl\` from the services section.
 3. **Use those values** as defaults for the test generation tool call. Do NOT ask the user for these values if they are already configured in the workspace file.
 4. **CRITICAL — endpointURL**: The \`endpointURL\` parameter MUST be the full URL to the specific endpoint being tested, NOT just the base URL. Construct it by combining \`api.baseUrl\` with the endpoint path. Example: if \`api.baseUrl\` is \`http://localhost:8000\` and the endpoint is \`/api/v1/products\`, pass \`endpointURL: "http://localhost:8000/api/v1/products"\`. NEVER pass just the base URL (e.g. \`http://localhost:8000\`) as \`endpointURL\`.
-5. **If the workspace file does not exist**, or the needed values (language, framework, outputDir) are missing from the workspace config, ASK the user which language and framework they want before calling the tool.
-6. The user can always override workspace defaults by explicitly specifying values in their request.
+5. **CRITICAL — scenario generation**: When calling \`skyramp_scenario_test_generation\`, ALWAYS pass:
+   - \`baseURL\`: The full base URL from \`api.baseUrl\` (e.g., \`http://localhost:3000\`). This determines the scheme, host, and port in the generated trace. Without it, the trace defaults to https:443 which is almost always wrong for local development.
+   - \`authHeader\`: The auth header name from \`api.authHeader\` in the workspace config. Use \`Cookie\` for cookie/session-based auth (NextAuth, etc.), \`Authorization\` for Bearer tokens, \`X-API-Key\` for API keys. Without it, the trace defaults to \`Authorization: Bearer\` which breaks cookie-based apps.
+   - \`apiSchema\` is OPTIONAL — omit it for code-first apps without OpenAPI specs.
+6. **CRITICAL — integration test from scenario**: When calling \`skyramp_integration_test_generation\` with a \`scenarioFile\`, ALSO pass \`authHeader\` (same value as used in scenario generation). This tells the CLI which header to parameterize with the auth token. Without it, the generated test defaults to \`Authorization: Bearer\` regardless of what's in the trace.
+7. **If the workspace file does not exist**, or the needed values (language, framework, outputDir) are missing from the workspace config, ASK the user which language and framework they want before calling the tool.
+8. The user can always override workspace defaults by explicitly specifying values in their request.
 `,
 });
 // Check for first-time invocation after version update (runs in background, doesn't block)
 let initCheckInFlight = false;
 let initCheckDone = false;
+const INIT_MESSAGE = "Skyramp init: Triggering pull of Skyramp worker and executor images if not present locally.";
 const originalRegisterTool = server.registerTool.bind(server);
 server.registerTool = function (name, definition, handler) {
     const wrappedHandler = async (...args) => {
+        let triggeredInitThisCall = false;
         if (!initCheckDone && !initCheckInFlight) {
             // Guard with inFlight so concurrent tool calls don't each spawn a new initCheck(),
             // but allow retry on failure (initCheckInFlight is reset to false on error).
@@ -96,6 +123,7 @@ server.registerTool = function (name, definition, handler) {
             // unreachable.  Deferring via setImmediate ensures the tool response is written to
             // stdout (and acknowledged by the MCP client) before any blocking FFI call runs.
             initCheckInFlight = true;
+            triggeredInitThisCall = true;
             setImmediate(() => {
                 initCheck()
                     .then(() => {
@@ -109,7 +137,15 @@ server.registerTool = function (name, definition, handler) {
                 });
             });
         }
-        return handler(...args);
+        const result = await handler(...args);
+        if (triggeredInitThisCall && result) {
+            const content = result.content ?? [];
+            result.content = [
+                { type: "text", text: INIT_MESSAGE },
+                ...content,
+            ];
+        }
+        return result;
     };
     return originalRegisterTool(name, definition, wrappedHandler);
 };
@@ -119,6 +155,7 @@ const prompts = [
     registerTestGenerationPrompt,
     registerStartTraceCollectionPrompt,
     registerTestHealthPrompt,
+    registerRecommendTestsPrompt,
 ];
 if (process.env.SKYRAMP_FEATURE_TESTBOT === "1") {
     prompts.push(registerTestbotPrompt);
@@ -148,8 +185,9 @@ const codeQualityTools = [
 codeQualityTools.forEach((registerTool) => registerTool(server));
 // Register test recommendation tools
 registerAnalyzeRepositoryTool(server);
-registerMapTestsTool(server);
 registerRecommendTestsTool(server);
+// Register analysis resources (MCP Resources for enriched data access)
+registerAnalysisResources(server);
 // Register test maintenance tools
 registerDiscoverTestsTool(server);
 registerAnalyzeTestDriftTool(server);

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

@@ -0,0 +1,101 @@
+function buildEnrichmentInstructions(p) {
+    const isDiffScope = p.analysisScope === "current_branch_diff";
+    if (!isDiffScope) {
+        return `## Your Task — Enrich & Recommend (full repo)
+
+### Step 1: Read key files
+Read \`package.json\` / \`requirements.txt\`, \`docker-compose.yml\`, route/controller files,
+and model/schema files (Zod schemas, Pydantic models, TypeScript interfaces, DTOs)
+to understand the tech stack, endpoint shapes, auth mechanisms, and request/response schemas.
+
+### Step 2: Identify resource relationships
+Map how endpoints relate to each other — which POST creates resources consumed by other endpoints?
+**Resolve nested/sub-router paths** from the Router Mounting section above.
+
+### Step 3: Call recommend tests
+Call \`skyramp_recommend_tests\` with \`sessionId: "${p.sessionId}"\``;
+    }
+    const changedFiles = p.parsedDiff?.changedFiles.join(", ") ?? "";
+    const hasApiEndpoints = p.parsedDiff && (p.parsedDiff.newEndpoints.length > 0 || p.parsedDiff.modifiedEndpoints.length > 0);
+    const isUIOnly = !hasApiEndpoints && (p.parsedDiff?.changedFiles.every(f => !f.match(/\/(api|routes?|controllers?|routers?|handlers?|endpoints?)\//)) ?? false);
+    const step2 = hasApiEndpoints
+        ? `### Step 2: Discover related endpoints
+Read handler code for the changed endpoints and their model/schema files (Zod schemas,
+Pydantic models, DTOs) to understand request/response shapes. Find related endpoints via
+imports, shared models, adjacent route files. Resolve nested/sub-router paths from Router
+Mounting context.`
+        : isUIOnly
+            ? `### Step 2: Identify consumed API endpoints
+UI-only PR — read changed components to find API calls (fetch, axios, hooks).`
+            : `### Step 2: Identify affected endpoints
+No API route changes detected — read changed files to identify affected endpoints.`;
+    return `## Your Task — Enrich & Recommend (PR-scoped)
+
+### Step 1: Read the changed files
+${changedFiles}
+
+${step2}
+
+### Step 3: Draft integration scenarios
+Draft multi-step scenarios simulating realistic user workflows:
+- **Cross-resource data flow**: Foreign key relationships, parent→child creation, verification
+- **Search/filter verification**: Create data, search, verify results
+- **Negative/error paths**: Invalid references → appropriate errors
+- **UI user journeys**: Concrete browser steps for frontend changes
+
+**Quality:** Realistic request bodies, response data verification, actual field names for chaining.
+
+### Step 4: Call recommend tests
+Call \`skyramp_recommend_tests\` with \`sessionId: "${p.sessionId}"\``;
+}
+export function buildAnalysisOutputText(p) {
+    const isDiffScope = p.analysisScope === "current_branch_diff";
+    const diffSection = p.parsedDiff
+        ? `
+## Branch Diff Context
+**Branch**: \`${p.parsedDiff.currentBranch}\` → base: \`${p.parsedDiff.baseBranch}\`
+**Changed Files** (${p.parsedDiff.changedFiles.length}): ${p.parsedDiff.changedFiles.join(", ")}
+**New Endpoints** (${p.parsedDiff.newEndpoints.length}): ${p.parsedDiff.newEndpoints.map((e) => `${e.method} ${e.path} (${e.sourceFile})`).join(", ") || "none"}
+**Modified Endpoints** (${p.parsedDiff.modifiedEndpoints.length}): ${p.parsedDiff.modifiedEndpoints.map((e) => `${e.method} ${e.path} (${e.sourceFile})`).join(", ") || "none"}
+**Affected Services**: ${p.parsedDiff.affectedServices.join(", ") || "none"}
+`
+        : "";
+    const endpointCatalog = p.scannedEndpoints.length > 0
+        ? `
+## Pre-Scanned Endpoint Catalog (${p.scannedEndpoints.length} routes)
+${p.scannedEndpoints.map((ep) => `  ${ep.methods.join("|")} ${ep.path} (${ep.sourceFile})`).join("\n")}
+`
+        : "";
+    const wsLine = p.wsBaseUrl
+        ? `**Base URL**: \`${p.wsBaseUrl}\` | **Auth header**: \`${p.wsAuthHeader || "Authorization"}\``
+        : "";
+    const specSection = p.wsSchemaPath
+        ? `
+## OpenAPI Spec Available
+Spec at \`${p.wsSchemaPath}\`. **Read it** for authoritative paths and schemas.
+Pass \`apiSchema: "${p.wsSchemaPath}"\` to ALL test generation tool calls.`
+        : p.routerMountContext
+            ? `
+## Router Mounting / Nesting
+\`\`\`
+${p.routerMountContext}
+\`\`\`
+Use this to resolve full URL paths for nested endpoints.`
+            : "";
+    const enrichment = buildEnrichmentInstructions(p);
+    return `# Repository Analysis
+
+**Session ID**: \`${p.sessionId}\`
+**Repository**: \`${p.repositoryPath}\`
+**Analysis Scope**: \`${p.analysisScope}\`
+${isDiffScope ? `**Diff endpoints**: ${(p.parsedDiff?.newEndpoints.length ?? 0) + (p.parsedDiff?.modifiedEndpoints.length ?? 0)}` : `**Pre-scanned endpoints**: ${p.scannedEndpoints.length}`}
+${wsLine}
+${p.wsSchemaPath ? `**OpenAPI Spec**: \`${p.wsSchemaPath}\` (spec-based flow)` : "**Flow**: Code-scanning (may miss nesting)"}
+
+${diffSection}
+${endpointCatalog}
+${specSection}
+${enrichment}
+
+**CRITICAL**: No .json/.md file creation. Prioritize cross-resource workflows.`;
+}

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

@@ -0,0 +1,193 @@
+export const MAX_TESTS_TO_GENERATE = 4;
+export const MAX_RECOMMENDATIONS = 10;
+export function buildPrioritizationDimensions() {
+    return `## Prioritization Dimensions (evaluate each candidate test)
+
+For each candidate test, assess these dimensions using your judgment:
+
+| Dimension | What to assess |
+|-----------|---------------|
+| **Sophistication** | Does it test a multi-step workflow or non-obvious scenario? Or is it a simple request→response check? |
+| **Bug-Finding Potential** | Does it target known failure modes (race conditions, data consistency, state transitions, cascade effects)? |
+| **User Journey Relevance** | Does it reflect how real users interact with the system (from traces, business flows, or critical paths)? |
+| **Coverage Gap** | Does it address an area with zero existing test coverage? Or does it duplicate what\'s already tested? |
+| **Code Insight** | Is it derived from actual implementation analysis (e.g., spotted a middleware pattern, found an N+1 risk) rather than just API shape? |
+
+Candidates scoring well across MULTIPLE dimensions should be recommended first.
+Candidates satisfying only ONE dimension (e.g., covers a gap but is trivially simple) should be deprioritized.
+
+**Quality Gate:** For each candidate, ask: "Would a senior engineer be impressed by this test?"
+If the answer is no — deprioritize it. Impressive tests catch real bugs, exercise real workflows,
+and demonstrate understanding of the system\'s behavior. Trivial tests do not.`;
+}
+export function buildTestExamples() {
+    return `## Test Examples (calibrate your judgment)
+
+**Impressive tests (recommend these):**
+1. "Register user → login → create order → verify order appears in user\'s order list"
+   Cross-resource workflow with auth chaining and data verification across users + orders.
+2. "Create product with inventory=10 → place order for qty=10 → verify inventory=0 →
+   place another order → verify 409 out-of-stock error"
+   Cross-resource state machine + business rule validation (products + orders + inventory).
+3. "POST /users with duplicate email → verify 409 Conflict → verify original user unchanged"
+   Error handling with side-effect verification — not just status code check.
+
+**Non-impressive tests (deprioritize or skip):**
+1. "GET /products → 200" — trivial health check, no assertions beyond status code.
+2. "POST /products → GET /products/{id} → PUT /products/{id} → DELETE /products/{id}"
+   Single-resource CRUD — baseline, not impressive by itself.
+3. "POST /products with missing name → 422" — obvious validation, already covered by contract/fuzz.`;
+}
+export function buildTestPatternGuidelines() {
+    return `## Test Pattern Guidelines (reference, not rigid rules)
+
+### Tier 1 — Base Patterns
+- CRUD lifecycle per resource group (Create → Read → Update → Delete)
+- Auth flow (Register → Login → Access protected → Token refresh → Logout)
+- Pagination & filtering (boundary values, empty results, large page sizes)
+- Error responses (400, 401, 403, 404, 409, 422 — each with specific trigger)
+
+### Tier 2 — Code-Informed Patterns (higher value — look for these in the codebase)
+- **Middleware chains**: If auth/rate-limit/logging middleware exists, test the chain
+  (e.g., rate limit hit → auth still checked → correct error returned)
+- **N+1 query risk**: If list endpoints join related data (e.g., orders with products),
+  test with large datasets under load
+- **State machines**: If resources have status transitions (draft→published→archived),
+  test invalid transitions (e.g., archived→draft should fail)
+- **Cascade deletes**: If deleting a parent removes children, verify cascade AND verify
+  orphan prevention (delete product → orders referencing it get error or cascade)
+- **Race conditions**: If concurrent writes are possible (inventory deduction, counter
+  increment), test concurrent requests under load
+- **Computed fields**: If response contains derived values (total, average, count),
+  verify computation with known inputs
+- **Webhook/event side effects**: If endpoints trigger async operations, test that side
+  effects occur (e.g., POST /orders triggers email notification)`;
+}
+export function buildTestQualityCriteria() {
+    return `## What Makes a Good Test
+
+**Integration tests** should demonstrate cross-resource data flow — step A creates data
+that step B depends on (e.g., create product \u2192 create order referencing that product's ID \u2192
+verify order contains correct product). Single-resource CRUD alone is not an integration test.
+Use realistic request bodies from source code schemas and verify response data, not just
+status codes.
+
+**E2E tests** should follow realistic user journeys end-to-end: browse products \u2192 search \u2192
+add to cart \u2192 checkout. Verify that frontend actions trigger the correct API calls and
+that the UI reflects backend state.
+
+**UI tests** should exercise component behavior and interaction flows: fill form \u2192 validate
+inputs \u2192 submit \u2192 see confirmation. Include visual state changes (loading, error, empty)
+and accessibility checks.`;
+}
+export function buildGenerationRules(isUIOnlyPR) {
+    return `## Generation Guidelines
+
+**Scenario fidelity:** Every workflow scenario should reflect the actual resource
+relationships in the code. If the pre-drafted scenarios don't match the real data model,
+replace them with accurate ones.
+
+**Available test types:**
+- **Integration** — multi-endpoint workflows that chain data across resources
+- **Fuzz** — boundary/invalid input testing for POST/PUT endpoints
+- **Contract** — response schema validation for new/changed endpoints
+- **E2E** — user journeys spanning frontend to backend (needs Playwright traces)
+- **UI** — frontend component interaction flows (needs Playwright traces)
+${isUIOnlyPR ? `
+This is a **UI-only PR** — no backend changes. UI and E2E tests are most relevant.
+Without Playwright traces, recommend them with trace recording instructions
+(\`skyramp_start_trace_collection\` with \`playwright: true\`).
+` : `
+When no Playwright trace exists, still recommend E2E/UI tests with instructions for
+recording a trace using \`skyramp_start_trace_collection\` with \`playwright: true\`.
+`}
+**No duplicate coverage.** If an existing test already covers an endpoint + test type,
+recommend a different test that adds new coverage.
+
+Choose the test types and distribution that maximize coverage for this specific PR.
+No smoke tests.`;
+}
+export function buildToolWorkflows(authHeaderValue) {
+    return `## How to Generate Tests — Tool Workflows
+
+**Auth Header:** \`authHeader: "${authHeaderValue}"\` — pass to EVERY tool call below.
+
+**For multi-endpoint workflows (integration tests) — Scenario → Integration pipeline:**
+1. Call \`skyramp_scenario_test_generation\` once per step: \`scenarioName\`, \`destination\`,
+   \`baseURL\`, \`method\`, \`path\`, \`requestBody\`, \`responseBody\`, \`authHeader: "${authHeaderValue}"\`.
+   \`statusCode\` is optional — defaults: POST→201, DELETE→204, GET/PUT/PATCH→200. Only override for non-standard codes.
+   **OpenAPI spec is NOT required.** \`apiSchema\` is OPTIONAL — omit it if no spec exists.
+   \`requestBody\` should use realistic field values from source code schemas (Zod, Pydantic, DTOs).
+   \`responseBody\` should match the actual API response shape from source code (including all fields
+   returned by the controller — e.g., \`id\`, \`ownerId\`, \`createdAt\`, included relations like \`collection\`, \`tags\`).
+   Wrap in \`{"response": ...}\` if the API uses an envelope pattern. If omitted, a synthetic response is generated.
+   Inspect the source code to determine the correct request AND response body shapes — avoid sending \`{}\`.
+   Use unique names with timestamp suffix to avoid conflicts on re-runs.
+   For GET/PUT/DELETE with path IDs, use a placeholder — chaining resolves the real ID.
+2. Produces a \`scenario_<name>.json\` in the same \`outputDir\` as the test files (not \`.skyramp/\`).
+3. Call \`skyramp_integration_test_generation\` with \`scenarioFile\` AND \`authHeader: "${authHeaderValue}"\`.
+   Do NOT pass \`chainingKey\` — defaults to \`response.id\`. After generation, the testbot
+   will verify and fix path param chaining in the generated test.
+
+**For single-endpoint tests (contract/fuzz):**
+\`skyramp_{type}_test_generation\` with \`endpointURL\` (full URL incl. base + path), \`method\`,
+\`authHeader: "${authHeaderValue}"\`, and \`requestData\` from source code schemas.
+If an OpenAPI spec exists, ALSO pass \`apiSchema\` — it enables schema-aware validation
+(contract tests verify response structure, fuzz tests generate smarter boundary values).
+Without a spec, \`endpointURL\` alone is sufficient.
+
+**For UI tests (no Playwright recording):**
+1. \`skyramp_start_trace_collection\` (playwright: true)
+2. Perform browser steps
+3. \`skyramp_stop_trace_collection\`
+4. \`skyramp_ui_test_generation\` with playwright zip
+
+**For E2E tests:**
+Same trace flow, pass both trace file and playwright zip to \`skyramp_e2e_test_generation\`.`;
+}
+export function buildCoverageChecklist(openApiSpec, isUIOnlyPR, topN, maxGenerate = MAX_TESTS_TO_GENERATE) {
+    const specNote = openApiSpec
+        ? `\n**OpenAPI Spec available**: \`${openApiSpec.path}\`
+Use it actively:
+- **Contract tests**: pass \`apiSchema: "${openApiSpec.path}"\` — the CLI validates response schemas against the spec.
+- **Fuzz tests**: pass \`apiSchema: "${openApiSpec.path}"\` — the CLI generates boundary values from schema constraints.
+- **Integration tests**: pass \`apiSchema\` to \`skyramp_scenario_test_generation\` — it extracts destination and request/response shapes.
+- **Single-endpoint tests**: pass both \`endpointURL\` AND \`apiSchema\` for schema-aware generation.
+\n`
+        : "";
+    return `## Coverage Checklist
+${specNote}
+${isUIOnlyPR ? `**UI-only PR** — no backend changes.
+Without Playwright traces, the testbot skips generation entirely — all recommendations
+become additionalRecommendations in the report.
+` : `**Available test types:** integration, fuzz, contract, E2E, UI. No smoke tests.
+Choose based on what adds the most value for this PR's changes.
+`}
+## For Each Recommendation Include:
+1. Test type  2. Priority (high/medium/low)  3. Target endpoint/scenario
+4. What it validates (business logic, not just "tests the endpoint")
+5. Skyramp tool call details — exact tool + key params for zero-editing execution
+6. For integration/E2E: reference draftedScenario by scenarioName
+
+## When Artifacts Are Missing
+Recommend the test anyway — never mark it "blocked":
+- **No OpenAPI spec** \u2192 use \`endpointURL\` and \`requestBody\` from source code
+- **No Playwright recording** \u2192 provide trace recording instructions
+- **No backend trace** \u2192 use the scenario generation pipeline
+
+## Select the Top ${topN}
+Consider all possible tests (endpoints \u00d7 interaction types + scenarios), then select the
+top ${topN} most valuable. Include \`totalConsidered\` count in your output. The top ${Math.min(maxGenerate, topN)} will
+be generated; ${topN > maxGenerate ? `recommendations #${Math.min(maxGenerate, topN) + 1}\u2013${topN} go to additionalRecommendations in the report,
+so ensure the top ${Math.min(maxGenerate, topN)} are the highest-impact tests.` : `all will be generated.`}
+
+- Each integration scenario's step sequence should be logically valid — preconditions
+  met by prior steps.
+
+Each recommendation should include enough detail for direct tool invocation.
+Reference draftedScenarios by name and interactions by description.
+Use "high"/"medium"/"low" for priority — no numeric scores.
+Total candidates should be \u2265 ${topN}.
+
+Generate recommendations now.`;
+}

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

@@ -0,0 +1,65 @@
+import { z } from "zod";
+import { StateManager, getSessionFilePath, hasSessionData, getSessionData, } from "../../utils/AnalysisStateManager.js";
+import { logger } from "../../utils/logger.js";
+import { buildRecommendationPrompt } from "./test-recommendation-prompt.js";
+import { getWorkspaceAuthHeader } from "../../utils/workspaceAuth.js";
+export function registerRecommendTestsPrompt(server) {
+    server.registerPrompt("skyramp_recommend_tests", {
+        description: "Generate test recommendations from enriched repository analysis. " +
+            "Provide a sessionId from skyramp_analyze_repository.",
+        argsSchema: {
+            sessionId: z
+                .string()
+                .describe("Session ID from skyramp_analyze_repository"),
+            scope: z
+                .enum(["full_repo", "current_branch_diff"])
+                .default("full_repo")
+                .optional()
+                .describe("Analysis scope (defaults to the scope used during analysis)"),
+        },
+    }, async (args) => {
+        const sessionId = args.sessionId;
+        if (!sessionId) {
+            throw new Error("sessionId is required");
+        }
+        // Try process memory first, then fall back to state file
+        let data = null;
+        if (hasSessionData(sessionId)) {
+            data = getSessionData(sessionId);
+        }
+        else {
+            const registeredPath = getSessionFilePath(sessionId);
+            const mgr = registeredPath
+                ? StateManager.fromStatePath(registeredPath)
+                : StateManager.fromSessionId(sessionId);
+            if (!mgr.exists()) {
+                throw new Error(`Analysis session "${sessionId}" not found. Run skyramp_analyze_repository first.`);
+            }
+            data = await mgr.readData();
+        }
+        if (!data?.analysis) {
+            throw new Error(`Session "${sessionId}" has no analysis data.`);
+        }
+        const scope = args.scope || data.analysisScope || "full_repo";
+        const effectiveTopN = scope === "current_branch_diff" ? 7 : 10;
+        const workspaceAuthHeader = data.repositoryPath
+            ? await getWorkspaceAuthHeader(data.repositoryPath)
+            : undefined;
+        const prompt = buildRecommendationPrompt(data.analysis, scope, effectiveTopN, data.prContext, workspaceAuthHeader);
+        logger.info("Serving recommendation prompt via MCP Prompt", {
+            sessionId,
+            scope,
+        });
+        return {
+            messages: [
+                {
+                    role: "user",
+                    content: {
+                        type: "text",
+                        text: `Session: ${sessionId}\nRepository: ${data.repositoryPath}\nScope: ${scope}\n\nAvailable MCP Resources:\n- skyramp://analysis/${sessionId}/summary\n- skyramp://analysis/${sessionId}/endpoints\n- skyramp://analysis/${sessionId}/scenarios\n- skyramp://analysis/${sessionId}/diff\n\n${prompt}`,
+                    },
+                },
+            ],
+        };
+    });
+}