@skyramp/mcp 0.0.58 → 0.0.60-rc.1

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:
 
@@ -75,8 +95,13 @@ 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)
@@ -116,6 +141,7 @@ const prompts = [
     registerTestGenerationPrompt,
     registerStartTraceCollectionPrompt,
     registerTestHealthPrompt,
+    registerRecommendTestsPrompt,
 ];
 if (process.env.SKYRAMP_FEATURE_TESTBOT === "1") {
     prompts.push(registerTestbotPrompt);
@@ -145,8 +171,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,98 @@
+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\`, and route/controller files
+to understand the tech stack, endpoint shapes, and auth mechanisms.
+
+### 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 changed API endpoints. 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,209 @@
+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 `## ⭐ MANDATORY — Meaningful Integration & E2E Tests
+
+**What makes a MEANINGFUL integration test (all 3 required):**
+1. **Cross-resource data flow** — Step A creates data that Step B depends on (e.g., create
+   product → create order referencing that product's ID → verify order contains correct product).
+   A test that just does CRUD on a single resource is NOT an integration test.
+2. **Realistic request bodies** — Use domain-appropriate data from the source code schemas.
+   Product tests should use real field names (name, price, category), not placeholders.
+   Order tests should reference actual product IDs from prior steps, not hardcoded "1".
+3. **Verification assertions** — Each test MUST verify the response DATA, not just status
+   codes. After creating an order, GET it and verify it contains the correct product_id,
+   quantity, and computed total. After searching products, verify the results match the query.
+
+**What makes a MEANINGFUL E2E test:**
+1. **Realistic user journey** — A real user flow from start to finish: browse products →
+   search/filter → add to cart → checkout. NOT just "navigate to /products and check 200".
+2. **Frontend-to-backend validation** — Verify that frontend actions trigger the correct API
+   calls and that the UI reflects the backend state correctly.
+3. **Domain-specific scenarios** — If the PR adds search, test: enter search term → verify
+   results appear → click result → verify detail page loads with correct data.
+
+**What makes a MEANINGFUL UI test:**
+1. **Component behavior** — Test that UI components render correctly and respond to user
+   interactions (clicks, typing, form submissions).
+2. **Visual state changes** — Test loading states, error states, empty states.
+3. **User interaction flows** — Test complete interaction sequences: fill form → validate
+   inputs → submit → see confirmation. NOT just "page renders".
+4. **Accessibility** — Verify keyboard navigation, ARIA labels, and focus management.`;
+}
+export function buildGenerationRules(isUIOnlyPR) {
+    return `**RULE 1 (non-negotiable):** Every "workflow" scenario below MUST become an integration
+test recommendation. But ALSO: if the pre-drafted scenarios don't reflect actual resource
+relationships in the code, **replace them** with scenarios that reflect the REAL data model.
+
+**RULE 2: Priority ordering — integration tests DOMINATE, but UI/E2E are MANDATORY for frontend changes:**
+1. **Multi-resource integration tests** (HIGHEST PRIORITY) — one for EACH cross-resource
+   workflow scenario. Generate AT LEAST 2 when 2+ resources exist.
+2. **CRUD lifecycle integration tests** — one for EACH resource with new/changed endpoints.
+3. **E2E tests** — one for EACH distinct user flow spanning frontend → backend.
+4. **UI tests** — one for EACH changed frontend component/page with meaningful interactions.
+   **If no Playwright trace exists, still recommend the test and provide step-by-step instructions
+   for the user to record a trace using \`skyramp_start_trace_collection\` with \`playwright: true\`.**
+5. **Fuzz tests** — one for EACH POST/PUT endpoint with request body validation.
+6. **Contract tests** — one for EACH endpoint with a new/changed response schema.
+7. **NEVER generate smoke tests. Zero smoke tests. Not even one.**
+
+**RULE 2a (MANDATORY): When changed files include frontend components/pages/views:**
+- At least 1 of the top 7 MUST be a UI test for a changed component.
+- At least 1 of the top 7 MUST be an E2E test for a user flow involving the changed UI.
+- If Playwright trace is missing, set \`frontendTrace\` to a message like:
+  "Requires Playwright recording — run \`skyramp_start_trace_collection\` with playwright:true"
+
+**RULE 3: No duplicate coverage.**
+Do NOT generate a test if an existing test already covers that endpoint × test type.
+If \`products_integration_test.py\` already exists covering CRUD products, recommend a
+multi-resource workflow that INCLUDES products alongside other resources instead.`;
+}
+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\`, \`statusCode\`, \`authHeader: "${authHeaderValue}"\`.
+   **OpenAPI spec is NOT required.** \`apiSchema\` is OPTIONAL — omit it if no spec exists.
+   \`requestBody\` MUST use realistic field values from source code schemas (Zod, Pydantic, DTOs).
+   Never send \`{}\` — inspect the source code to determine the correct request body shape.
+   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\` capturing the multi-step flow.
+3. Call \`skyramp_integration_test_generation\` with \`scenarioFile\` AND \`authHeader: "${authHeaderValue}"\`.
+   Do NOT pass \`chainingKey\` — auto-set to \`response.id\`.
+
+**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.
+**OpenAPI is NOT required** — \`endpointURL\` is sufficient. Only pass \`apiSchema\` if one exists.
+
+**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, hasFrontendChanges, authHeaderValue, topN) {
+    const specNote = openApiSpec
+        ? `\n**OpenAPI Spec**: \`${openApiSpec.path}\` — pass \`apiSchema: "${openApiSpec.path}"\` to ALL tool calls.\n`
+        : "";
+    const distribution = isUIOnlyPR
+        ? `- ≥50% UI tests, ≥30% E2E tests, remaining: integration. 0% fuzz/contract/smoke.`
+        : hasFrontendChanges
+            ? `- ≥30% integration, ≥20% E2E, ≥15% UI (at least 1 UI + 1 E2E MANDATORY). Remaining: fuzz + contract. 0% smoke.`
+            : `- ≥60% integration (multi-resource FIRST, then CRUD). Remaining: fuzz + contract. 0% smoke.`;
+    const skipUI = isUIOnlyPR ? " (Skip for UI-only PRs)" : "";
+    return `## Coverage Checklist
+${specNote}
+For EACH endpoint, recommend ALL applicable types **that don't already exist**:
+1. **Integration** (HIGHEST) — per workflow scenario + per resource CRUD.
+2. **E2E** — per user flow spanning frontend → backend.
+3. **UI** — per changed component/page.${isUIOnlyPR ? " **PRIMARY for this PR.**" : ""}
+4. **Fuzz** — per POST/PUT with request body.${skipUI}
+5. **Contract** — per new/changed response schema.${skipUI}
+6. **NO smoke tests.**
+
+## For Each Recommendation:
+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 — NEVER mark "blocked", NEVER skip the recommendation:
+- **No OpenAPI spec** → use \`endpointURL\` (full URL) and \`requestBody\` from source code.
+  Scenario generation, contract, fuzz, and integration tests ALL work without OpenAPI.
+- **No Playwright recording** → recommend the UI/E2E test anyway. Provide step-by-step
+  instructions for the user to record a trace with \`skyramp_start_trace_collection\`.
+- **No backend trace** → recommend the test anyway. Use scenario generation pipeline instead.
+
+## Generate Many, Show Few
+Internally consider ALL possible tests from the endpoint catalog (endpoints × interaction types
++ scenarios). Then select the top ${topN} most valuable, ranked by priority. In your output, include:
+- \`totalConsidered: <number>\` — how many candidate tests you evaluated
+- The curated top ${topN} recommendations, ranked #1 (highest value) to #${topN}
+- The top 4 will be generated and executed; recommendations #5-#${topN} will be reported but not generated.
+  Therefore, ensure the top 4 are the most impactful tests. For mixed PRs with frontend changes,
+  the top 4 MUST include at least 1 E2E or UI test alongside integration tests.
+
+Prioritize integration/E2E, fill with fuzz/contract.
+${distribution}
+
+## MANDATORY RULES:
+1. "high"/"medium"/"low" only — no numeric scores.
+2. Never mark "blocked". 3. No file creation. 4. Order: integration → E2E → UI → fuzz → contract.
+5. Reference draftedScenarios by name. 6. Reference interactions by description.
+7. Every recommendation = enough detail for direct tool invocation.
+
+**FINAL CHECK:** Count: workflow scenarios → integration tests, resources → CRUD tests,
+user flows → E2E, components → UI, POST/PUT → fuzz${skipUI}, schemas → contract${skipUI}.
+Total must be ≥ ${topN}.
+
+Generate recommendations now.`;
+}

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

@@ -0,0 +1,71 @@
+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)"),
+            focus: z
+                .enum(["all", "interactions", "scenarios"])
+                .default("all")
+                .optional()
+                .describe("Focus area: all tests, interaction-based (contract/fuzz), or scenario-based (integration/e2e)"),
+        },
+    }, 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 focus = args.focus || "all";
+        const effectiveTopN = scope === "current_branch_diff" ? 7 : 10;
+        const workspaceAuthHeader = data.repositoryPath
+            ? await getWorkspaceAuthHeader(data.repositoryPath)
+            : undefined;
+        const prompt = buildRecommendationPrompt(data.analysis, scope, focus, 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}`,
+                    },
+                },
+            ],
+        };
+    });
+}