@skyramp/mcp 0.0.31 → 0.0.33

package/build/index.js

@@ -18,15 +18,18 @@ import { registerLoginTool } from "./tools/loginTool.js";
 import { registerLogoutTool } from "./tools/logoutTool.js";
 import { registerFixErrorTool } from "./tools/fixErrorTool.js";
 import { registerModularizationTool } from "./tools/modularizationTool.js";
+import { registerCodeReuseTool } from "./tools/codeReuseTool.js";
+import { registerScenarioTestTool } from "./tools/generateScenarioRestTool.js";
 const server = new McpServer({
     name: "Skyramp MCP Server",
     version: "1.0.0",
     capabilities: {
-        resources: {},
-        tools: {},
-        prompts: {},
-        sampling: {},
-        elicitation: {},
+        tools: {
+            listChanged: true,
+        },
+        prompts: {
+            listChanged: true,
+        },
     },
 });
 // Register prompts
@@ -42,9 +45,11 @@ registerLoadTestTool(server);
 registerIntegrationTestTool(server);
 registerE2ETestTool(server);
 registerUITestTool(server);
+registerScenarioTestTool(server);
 // Register modularization and fix error tools
 registerModularizationTool(server);
 registerFixErrorTool(server);
+registerCodeReuseTool(server);
 // Register other Skyramp tools
 registerLoginTool(server);
 registerLogoutTool(server);
@@ -56,6 +61,20 @@ async function main() {
     const transport = new StdioServerTransport();
     await server.connect(transport);
     logger.info("MCP Server started successfully");
+    // Listen for stdin closure (parent process disconnected)
+    process.stdin.on("end", () => {
+        logger.info("STDIN closed, parent process disconnected. Exiting...");
+        process.exit(0);
+    });
+    // Handle process termination signals
+    process.on("SIGTERM", () => {
+        logger.info("Received SIGTERM, shutting down gracefully...");
+        process.exit(0);
+    });
+    process.on("SIGINT", () => {
+        logger.info("Received SIGINT, shutting down gracefully...");
+        process.exit(0);
+    });
 }
 main().catch((error) => {
     logger.critical("Fatal error in main()", {

package/build/prompts/code-reuse.js

@@ -0,0 +1,151 @@
+import { generateSkyrampHeader, SKYRAMP_UTILS_HEADER } from "../utils/utils.js";
+const LANGUAGE_MAP = {
+    python: {
+        extension: "py",
+        fileName: "SkyrampUtils.py",
+    },
+    java: {
+        extension: "java",
+        fileName: "SkyrampUtils.java",
+    },
+    javascript: {
+        extension: "js",
+        fileName: "skyrampUtils.js",
+    },
+    typescript: {
+        extension: "ts",
+        fileName: "skyrampUtils.ts",
+    },
+};
+export function getCodeReusePrompt(testFile, language) {
+    const ext = LANGUAGE_MAP[language].extension || "py";
+    const fileName = LANGUAGE_MAP[language].fileName || "SkyrampUtils.py";
+    return `# CODE REUSE - 6 CLEAR STEPS 
+**CRITICAL WARNING: VIOLATION OF THESE RULES WILL RESULT IN ERROR**
+
+## DEFINITIONS (READ FIRST):
+**What is a "Helper Function"?**
+- A helper function is a STANDALONE, DISTINCT function that is ALREADY DEFINED in the code
+- It has a clear function signature (e.g., \`async function createProduct(page, data) { ... }\`)
+- It is NOT just repetitive inline test code or patterns
+- Example of helper function: \`async function loginUser(page, email, password) { ... }\`
+- Example of NOT a helper function: Repetitive \`await page.click()\` statements scattered in test
+
+**What is "Repetitive Code Pattern"?**
+- Sequential test steps that look similar but are NOT extracted into standalone functions
+- Example: Multiple sequences of \`await page.fill()\`, \`await page.click()\` directly in test body
+- These patterns should NOT be extracted during code reuse - that's what modularization is for
+
+🚨 **CODE REUSE ≠ REFACTORING** 🚨
+- Code reuse = Finding EXISTING helper functions and reusing them
+- Refactoring = Creating NEW helper functions from patterns (handled by modularization tool)
+
+## STEP 1: READ TEST FILE
+Read ${testFile} and look for ALREADY DEFINED helper functions (not just repetitive patterns).
+
+## STEP 2: FIND EXISTING UTILS
+Use the Grep tool to search for files containing "${SKYRAMP_UTILS_HEADER}":
+- Pattern: "${SKYRAMP_UTILS_HEADER}"
+- Type: "${ext}"
+- Output mode: "files_with_matches"
+**CRITICAL: Only look for util files with header ${SKYRAMP_UTILS_HEADER}** - exclude test files (files with "test", "spec", ".test.", ".spec." in the name).
+Read the matching non-test files and check if any helpers can be reused in ${testFile}.
+
+## STEP 3: USE EXISTING HELPERS FROM UTILS SOURCE FILES FOUND IN STEP 2
+If helpers exist in util file that can be reused in ${testFile} without modifying them:
+- Import them into ${testFile}
+- Remove any duplicate code in ${testFile}
+- Test that ${testFile} still works without any errors and logical is same as original test file.
+
+## STEP 4: FIND LOCAL HELPERS IN OTHER TEST SOURCE FILES THAT HAS HEADER ${SKYRAMP_UTILS_HEADER} 
+Use the Grep tool to search for other test files containing "${SKYRAMP_UTILS_HEADER}":
+- Pattern: "${SKYRAMP_UTILS_HEADER}"
+- Type: "${ext}"
+- Output mode: "files_with_matches"
+**CRITICAL: Exclude ${testFile} from the results** - only look at OTHER test files, not the current file.
+
+🚨 **STOP HERE IF NO OTHER TEST FILES FOUND** 🚨
+**IF NO OTHER TEST FILES ARE FOUND, SKIP TO STEP 6 - DO NOT CREATE ANY UTILS FILES.**
+
+If other test files are found, read those files and look for ALREADY DEFINED helper functions with clear function signatures.
+
+**How to identify helper functions in other test files:**
+✅ HELPER FUNCTION (move to utils):
+   - Has function signature: \`async function doSomething(params) { ... }\`
+   - Can be called multiple times with different parameters
+   - Example: \`async function fillProductForm(page, product) { ... }\`
+
+❌ NOT A HELPER FUNCTION (do not extract):
+   - Just repetitive inline test code in test body
+   - No function definition/signature
+   - Example: Multiple \`await page.getByTestId("xyz").click()\` directly in test
+
+🚨 **IF OTHER TEST FILES ONLY CONTAIN REPETITIVE PATTERNS (NO ACTUAL HELPER FUNCTIONS), SKIP TO STEP 6** 🚨
+🚨 **IF OTHER TEST FILES ARE ESSENTIALLY IDENTICAL TO CURRENT FILE, SKIP TO STEP 6** 🚨
+
+## STEP 5: IF LOCAL HELPERS ARE FOUND IN STEP 4 THAT CAN BE REUSED in ${testFile}, MOVE THOSE LOCAL HELPERS TO UTILS SOURCE FILES AND USE THEM
+
+🚨 **ONLY PROCEED WITH STEP 5 IF ALL CONDITIONS ARE MET:** 🚨
+- ✅ You found OTHER test files in STEP 4 (not just ${testFile})
+- ✅ Those test files contain ACTUAL HELPER FUNCTIONS with function signatures (not just repetitive patterns)
+- ✅ The helper functions are ALREADY IMPLEMENTED and working in those OTHER test files
+- ✅ The helper functions are DIFFERENT from the current file (not just identical patterns)
+
+🚨 **IF ANY CONDITION IS NOT MET, SKIP TO STEP 6 - DO NOT CREATE ANY UTILS FILES.** 🚨
+
+**Examples of when to SKIP STEP 5:**
+- ❌ Other test files have identical repetitive code but no helper functions
+- ❌ Other test files are generated from same template and look identical
+- ❌ You see patterns but no actual function definitions
+- ❌ You would need to CREATE new functions to extract the patterns
+
+**CRITICAL:** For helpers found in STEP 4:
+1. **CREATE** \`${fileName}\` file if it doesn't exist with the following header:
+   \`\`\`${ext}
+   ${generateSkyrampHeader(language)}
+   \`\`\`
+**CRITICAL: IF \`${fileName}\` is already big, create a new file with a different name and add the header to the new file.**
+2. **COPY** those local helper functions from original test source files to \`${fileName}\` without modifying them
+3. **DELETE** those local helper functions from test source files (REMOVE THEM COMPLETELY) WITHOUT ANY OTHER CHANGES.
+4. **IMPORT** those local helper functions from \`${fileName}\` back into test source files WITHOUT MAKING ANY OTHER CHANGE.
+5. **IMPORT** those local helper functions from \`${fileName}\` into ${testFile}
+6. **REPLACE** duplicate code in ${testFile} with calls to imported helper functions WITHOUT MAKING ANY OTHER CHANGE.
+
+🚨 **CRITICAL: DO NOT CREATE UNNECESSARY HELPER FUNCTIONS** 🚨
+🚨 **DO NOT CREATE HELPERS BASED ON PATTERNS IN THE CURRENT FILE** 🚨
+
+## STEP 6: VERIFY AND VALIDATE
+1. **BEFORE** making any changes, read the original test file and identify ALL helper functions
+2. **AFTER** copying helpers to utils, read the original file again to confirm helpers are GONE
+3. **VERIFY** that helper functions are NO LONGER in original test files
+4. **VERIFY** that the original test files only have import statements and no duplicate code
+5. **VERIFY** that both original and new test files import from utils and use the helper functions
+6. **VERIFY** that no unnecessary helper functions were created (functions that duplicate existing functionality)
+7. **VERIFY** that all helper functions in utils are actually imported and used in the test files
+8. **REMOVE** any helper functions that are not being used after refactoring
+9. **NEVER** refactor, reorganize, or restructure existing source test files beyond moving helpers
+10. **RUN TESTS** to ensure functionality is preserved after refactoring
+
+🚨 **FINAL REMINDER: DO NOT CREATE HELPER FUNCTIONS FROM SCRATCH** 🚨
+🚨 **ONLY MOVE EXISTING HELPERS FROM OTHER TEST FILES** 🚨
+
+**IMPORTANT NOTES:**
+- The process is designed to REUSE existing helper functions, not create new ones
+- If no existing helpers are found, the test file should remain unchanged
+- Code reuse is about moving existing, working helper functions between files
+- Never create helper functions based on patterns you see in the current test file
+- Helper functions must have explicit function signatures/definitions
+- Repetitive inline test code is NOT a helper function
+
+**DECISION TREE:**
+1. Found existing utils file with helpers? → Import and use them (Step 3)
+2. Found other test files with ACTUAL helper functions? → Move to utils (Step 5)
+3. Found other test files with only repetitive patterns? → SKIP to Step 6, NO utils file
+4. Found no other test files? → SKIP to Step 6, NO utils file
+5. Other test files identical to current? → SKIP to Step 6, NO utils file
+
+**MANDATORY**: After code reuse is complete, proceed to modularization by calling skyramp_modularization tool
+
+SUMMARIZE THE CODE REUSE PROCESS AND THE RESULTS.
+`;
+}

package/build/prompts/fix-error-prompt.js

@@ -0,0 +1,29 @@
+export function getFixErrorsPrompt() {
+    return `
+**Fix errors in refactored code.**
+
+1. **Parameter Passing:** Identify functions using variables from outside scope (like 'page' object). Pass these as parameters.
+2. **Validate Correctness:** Ensure code is free of reference errors, undefined variables, runtime issues.
+3. **Import Paths:** Ensure import paths are correct and there are no circular imports.
+4. **Import Validation:** Ensure all remaining imports are necessary and no missing imports cause reference errors.
+5. **Unused Import Cleanup:** Verify that unused imports were properly removed without breaking functionality.
+6. **UI State Management:** Check for UI state conflicts, modal interference, or element interaction issues.
+7. **Sequential Operations:** Ensure UI operations don't interfere with each other when called in sequence.
+
+**IMPORT ERROR DEBUGGING:**
+- Check for missing imports that cause undefined reference errors
+- Verify that import removal didn't break existing functionality
+- Ensure all imported modules are actually available in the project
+- Confirm that import syntax is correct for the target language
+
+**CRITICAL CONSTRAINTS:**
+- DO NOT CREATE/UPDATE package.json or requirements.txt or pom.xml or build.gradle file
+- NEVER create dependency management files, even when linting errors suggest missing dependencies
+- Focus on fixing code errors within existing files only
+
+**KEY: Variables not defined within function scope MUST be passed as parameters.**
+**UI KEY: Helper functions that perform UI operations must be self-contained and not leave modals/dialogs open.**
+**IMPORT KEY: All imports must be either used in the code or properly removed.**
+**DEPENDENCY KEY: DO NOT create package.json, requirements.txt, or any dependency files regardless of linting errors.**
+`;
+}

package/build/prompts/modularization/integration-test-modularization.js

@@ -0,0 +1,92 @@
+export function getModularizationPrompt(filePath) {
+    return `# INTEGRATION TEST MODULARIZATION - SIMPLE AND SAFE
+
+**WRITE MODULARIZED CODE TO: ${filePath}**
+
+**ABSOLUTELY FORBIDDEN:**
+- DO NOT CREATE ANY INTERFACES, CLASSES, TYPES, OR NEW DATA STRUCTURES. USE INLINE TYPES ONLY.
+- DO NOT CREATE/UPDATE package.json or requirements.txt or pom.xml or build.gradle file
+- DO NOT CHANGE TEST LOGIC, DATA VALUES, ASSERTIONS, OR API CALLS
+- DO NOT MODIFY EXPECTED RESPONSES OR STATUS CODES
+
+## STEP 1: READ AND UNDERSTAND THE ORIGINAL TEST
+**CRITICAL: Before making ANY changes:**
+1. Read ${filePath} completely
+2. Identify all API endpoints and their parameters
+3. Identify all test data (request bodies, expected responses)
+4. Identify all assertions and expected values
+5. Document the test flow
+6. **DO NOT PROCEED** until you fully understand what the test does
+
+## STEP 2: FIND REPETITIVE CODE
+Look for API calls that repeat 2+ times with IDENTICAL structure but different data.
+
+## STEP 3: CREATE HELPER FUNCTIONS - EXTRACT ONLY, NO CHANGES
+
+**GOLDEN RULE: COPY-PASTE THE ORIGINAL CODE INTO HELPERS, JUST ADD PARAMETERS AND REPLACE HARDCODED VALUES WITH PARAMETERS**
+
+**CRITICAL RULES:**
+1. **EXACT CODE COPY** - Copy the API call code EXACTLY as-is from the original test
+2. **ONLY ADD PARAMETERS** - The ONLY change allowed is converting hardcoded values to parameters
+3. **NO LOGIC CHANGES** - Do not modify conditions, validations, or assertions
+4. **NO DATA CHANGES** - Do not change any request/response values or expected results
+5. **PRESERVE PATH PARAMETERS** - API path parameters must be passed as function parameters
+6. **PRESERVE ORDER** - Keep all operations in the exact same order
+
+**PARAMETER CONVERSION RULES:**
+- Find the values that DIFFER between repetitions (e.g., user IDs, product names)
+- Make ONLY those differing values into parameters
+- Keep everything else EXACTLY the same
+
+**EXAMPLE OF CORRECT EXTRACTION:**
+\`\`\`typescript
+// Original repetitive code:
+const response1 = await fetch("/api/users/1");
+expect(response1.status).toBe(200);
+
+const response2 = await fetch("/api/users/2");
+expect(response2.status).toBe(200);
+
+// Correct helper (EXACT copy + parameters):
+async function getUser(userId: number) {
+  const response = await fetch(\`/api/users/\${userId}\`);
+  expect(response.status).toBe(200);
+  return response;
+}
+\`\`\`
+
+**WHAT NOT TO DO:**
+❌ Changing API endpoints
+❌ Modifying expected status codes
+❌ Changing request/response validation
+❌ Reordering operations
+❌ "Improving" error handling
+❌ Adding new assertions
+
+## STEP 4: USE HELPERS WITH EXACT SAME DATA
+When calling the helpers, use the EXACT same values from the original test.
+
+## STEP 5: FINAL VERIFICATION
+
+**BEFORE WRITING ANY CODE, VERIFY:**
+- [ ] I have read and understood the original test completely
+- [ ] I have identified all API calls and their parameters
+- [ ] I have documented all expected responses and assertions
+- [ ] I understand the exact test flow and logic
+
+**AFTER EXTRACTION, VERIFY:**
+- [ ] Helper functions are EXACT copies of original code + parameters only
+- [ ] NO API endpoints have been changed
+- [ ] NO expected status codes or responses have been modified
+- [ ] ALL test data values match the original test exactly
+- [ ] Helper calls use the EXACT same values from the original test
+- [ ] NO duplicate API call code remains in main test
+
+**FINAL SANITY CHECK:**
+Run through the modularized test mentally:
+1. Does it make the exact same API calls?
+2. Does it use the exact same request data?
+3. Does it expect the exact same responses?
+
+If ANY answer is "no", DO NOT submit - fix the modularization first.`;
+}

package/build/prompts/modularization/ui-test-modularization.js

@@ -0,0 +1,164 @@
+export function getModularizationPrompt(filePath) {
+    return `# UI TEST MODULARIZATION - IMPROVE READABILITY AND REDUCE DUPLICATION
+
+**WRITE MODULARIZED CODE TO: ${filePath}**
+
+**ABSOLUTELY FORBIDDEN:**
+- DO NOT CREATE INTERFACES, CLASSES, TYPES, NEW FILES, OR NEW DATA STRUCTURES
+- DO NOT CHANGE TEST LOGIC, DATA VALUES, CALCULATIONS, OR ASSERTIONS
+- DO NOT CREATE/UPDATE  DEPENDENCY FILES package.json, requirements.txt, pom.xml, build.gradle file
+
+## STEP 1: READ THE ORIGINAL TEST
+Read ${filePath} completely and identify:
+- All test data values (names, prices, quantities, totals)
+- All test data including calculations and expected results 
+- The exact test flow
+- **Check if code is already modularized** (e.g., \`breakpoint_section_0\`, \`breakpoint_section_1\` functions)
+
+## STEP 2: HANDLE PRE-MODULARIZED CODE
+
+**IF CODE IS ALREADY MODULARIZED** (has functions like \`breakpoint_section_0\`, \`breakpoint_section_1\`):
+1. **RENAME** functions with meaningful names that describe what they do
+   - ❌ BAD: \`breakpoint_section_0\`, \`breakpoint_section_1\`
+   - ✅ GOOD: \`createProduct\`, \`editProductPrice\`, \`createOrder\`
+2. **PARAMETERIZE** hardcoded values in these functions
+3. **DO NOT** change the function logic or structure
+4. **DO NOT** create new functions - work with existing ones
+5. **SKIP to STEP 5** for verification
+
+**IF CODE IS NOT MODULARIZED**, proceed to STEP 3.
+
+## STEP 3: IDENTIFY EXTRACTION OPPORTUNITIES
+
+Extract code in TWO scenarios:
+
+**A) REPETITIVE CODE** - Code that repeats 2+ times with IDENTICAL structure but different data
+- Extract EACH occurrence as a separate helper call
+- Don't try to "unify" variations with conditional logic
+
+**B) LOGICAL SECTIONS** - Self-contained operations (5+ lines) that improve readability
+- Examples: "create product", "fill form", "verify result"
+- Must be cohesive - related operations that achieve one goal
+
+**Don't extract:**
+- Code less than 5 lines (unless highly repetitive)
+- Navigation sequences (\`navbar-\` clicks, \`page.goto\`)
+
+## STEP 3: EXTRACT INTO HELPERS
+
+**GOLDEN RULE: Copy the original code exactly, only add parameters for values that differ**
+
+**CRITICAL - AVOID BUGS:**
+- Copy the code block EXACTLY as-is from the original test
+- **VERIFY ALL field mappings** - EVERY \`.fill()\` must use the correct parameter
+  - ✅ CORRECT: quantity field → \`.fill(quantity.toString())\`
+  - ❌ WRONG: quantity field → \`.fill("12")\` then \`.fill(quantity.toString())\` - remove hardcoded "12"!
+  - ❌ WRONG: name field → \`.fill(description)\` - fields must match their data!
+- **Replace ALL hardcoded values with parameters** - No leftover hardcoded fills
+- **NEVER create new conditional logic** (no ternaries, no if/else, no loops to derive parameter values)
+- **NEVER add logic that wasn't in the original code**
+- Keep ALL existing logic, calculations, and assertions unchanged
+- Keep ALL lines in the same order (except: remove fills with wrong/temporary hardcoded values)
+
+**PARAMETERIZATION BEST PRACTICES:**
+1. **Use individual parameters, not data objects** - Makes helper usage clearer
+   - ✅ GOOD: \`createProduct(page, name, price, category)\`
+   - ❌ BAD: \`createProduct(page, productData)\` - unclear what fields are needed
+
+2. **Avoid nested helpers** - Keep helpers flat and independent
+   - ✅ GOOD: One helper does the complete operation
+   - ❌ BAD: Helper calls another helper - adds complexity
+
+3. **No duplicate helpers** - If you have 2+ helpers doing similar things, consolidate them
+   - ✅ GOOD: One \`createOrder(email, items)\` handles both simple and complex orders
+   - ❌ BAD: \`createSimpleOrder\` and \`createOrderWithItems\` - consolidate into one
+   - Exception: Keep separate if it significantly improves readability
+
+4. **For repetitive code**: Only parameterize values that DIFFER between occurrences
+
+5. **NEVER compute parameters**: Pass literal values directly, don't create logic to derive them
+
+6. **If you need conditionals to choose parameter values, extract each case separately instead**
+
+7. **Loops in helpers**: Generally avoid, but acceptable if:
+   - The loop existed in the original code, OR
+   - It significantly improves readability without changing test behavior
+   - Example: Looping through order items is acceptable if each item is explicitly listed at call site
+
+**NAVIGATION RULE:**
+- Keep \`navbar-\` clicks and main \`page.goto\` in the test body
+- Exception: Helper can include \`page.goto\` to navigate back after form submissions that redirect
+
+**WRONG - Bad practices:**
+\`\`\`typescript
+// ❌ DON'T DO THIS - Adding conditional logic to handle multiple cases
+async function addItem(page, index: number) {
+  const name = index === 1 ? "item1" : index === 2 ? "item2" : "item3";
+  await page.fill("#name", name);
+}
+
+// ❌ DON'T DO THIS - Duplicate actions
+async function createProduct(page, name) {
+  await page.click("#add-button");  // Helper clicks button
+  // ... rest of product creation
+}
+// Then in test:
+await page.click("#add-button");  // Test ALSO clicks button - DUPLICATE!
+await createProduct(page, "item1");
+
+// ❌ DON'T DO THIS - Multiple helpers for same operation
+async function createSimpleOrder(...) { }
+async function createOrderWithItems(...) { }
+// Should be ONE helper: createOrder(page, email, items)
+\`\`\`
+
+**RIGHT - Good practices:**
+\`\`\`typescript
+// ✅ CORRECT - Extract with parameter, no new logic
+async function addItem(page, name: string) {
+  await page.fill("#name", name);  // Replace literal with parameter
+}
+
+// ✅ CORRECT - Call helper for EACH original occurrence
+await addItem(page, "item1");
+await addItem(page, "item2");
+await addItem(page, "item3");
+
+\`\`\`
+
+## STEP 4: CALL HELPERS WITH EXACT SAME VALUES
+Use the EXACT same values from the original test when calling helpers.
+
+## STEP 5: VERIFY - CRITICAL CHECKS
+
+**BUGS TO AVOID:**
+- [ ] **ALL field mappings verified** - EVERY \`.fill()\` uses the correct parameter. Check field gets quantity parameter, NOT hardcoded 
+- [ ] **No duplicate helpers** - Consolidate similar helpers (e.g., one createOrder vs createSimpleOrder + createOrderWithItems)
+- [ ] **No nested helpers** - Helpers don't call other helpers unnecessarily
+- [ ] **Clear parameters** - Individual parameters (name, price) not data objects
+- [ ] **No duplicate actions** - Don't click "Add Product" button in test AND in helper - choose one place
+- [ ] **No new loops** - Exception: acceptable if it improves readability and items are explicit at call site
+
+**DATA INTEGRITY:**
+- [ ] Helpers are exact copies of original + parameters only
+- [ ] All data values match the original test exactly
+- [ ] All calculations produce identical results
+- [ ] Helper calls use the same values as original
+- [ ] No navigation code in helpers (except page.goto for state)
+- [ ] No duplicate code in main test
+
+**READABILITY:**
+- [ ] Helper names clearly describe what they do
+- [ ] Test flow is easy to follow
+- [ ] Helper signatures are clear (individual params > data objects)
+
+**FINAL CHECK:**
+1. Does the modularized test perform the exact same operations?
+2. With the exact same data?
+3. Expecting the exact same results?
+4. Is it MORE readable than the original?
+
+If ANY answer is "no", fix it before submitting.
+
+**When in doubt, don't extract - keep original code unchanged.**`;
+}

package/build/prompts/testGenerationPrompt.js

@@ -101,13 +101,89 @@ Let us generate an E2E test with backend trace file skyramp-traces.json and fron
 Let us generate a UI test with frontend playwright trace file skyramp_playwright.zip using Python language and Pytest framework.
 \`\`\`
 
+**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)
+- 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
+
+**Usage:**
+Describe any multi-step workflow in natural language, and the tool will parse it against your API schema to create a structured JSON array of API requests. Use this JSON output with other test generation tools.
+
 - Default Language: Python
 - Default Framework: Pytest
 - Supported Languages: Python, Java, JavaScript, TypeScript
 - Supported Frameworks: Pytest, Robot, JUnit, Playwright
 
+**Example Scenario Parsing:**
+Prompt: 
+Generate scenario for Skyramp Demo Shop API whose schema is https://demoshop.skyramp.dev/openapi.json   
+1. create a new product called Skyramp Tester which costs $999, for the other fields chose reasonable values 
+2. then create an order with 1x Skyramp Tester
+
+Trace File:
+[
+    {
+        "Source": "172.20.0.1:56948",
+        "Destination": "demoshop.skyramp.dev",
+        "RequestBody": "{\"name\":\"Skyramp Tester\",\"description\":\"Test Generation\",\"image_url\":\"images.google.com/skyramp.jpg\",\"category\":\"Software\",\"in_stock\":true,\"price\":999}",
+        "ResponseBody": "{\"name\":\"Skyramp Tester\",\"description\":\"Test Generation\",\"price\":999.0,\"image_url\":\"images.google.com/skyramp.jpg\",\"category\":\"Software\",\"in_stock\":true,\"product_id\":24,\"created_at\":\"2025-09-29T15:18:35.844599Z\",\"updated_at\":\"2025-09-29T15:18:35.844595Z\"}",
+        "RequestHeaders": {
+            "Content-Type": [
+                "application/json"
+            ],
+            "Authorization": [
+                "Bearer flat-tropical-vapor"
+            ]
+        },
+        "ResponseHeaders": {
+            "Content-Type": [
+                "application/json"
+            ]
+        },
+        "Method": "POST",
+        "Path": "/api/v1/products",
+        "QueryParams": {},
+        "StatusCode": 201,
+        "Port": 443,
+        "Timestamp": "2025-09-29T15:18:36.178356292Z",
+        "Scheme": "https"
+    },
+    {
+        "Source": "172.20.0.1:59186",
+        "Destination": "demoshop.skyramp.dev",
+        "RequestBody": "{\"customer_email\":\"kolja@skyramp.dev\",\"items\":[{\"product_id\":\"24\",\"quantity\":1}]}",
+        "ResponseBody": "{\"customer_email\":\"kolja@skyramp.dev\",\"status\":\"pending\",\"total_amount\":999.0,\"order_id\":13,\"items\":[{\"quantity\":1,\"product_id\":24,\"order_item_id\":24,\"order_id\":13}],\"created_at\":\"2025-09-29T15:18:51.024822\",\"updated_at\":\"2025-09-29T15:18:51.024827\"}",
+        "RequestHeaders": {
+            "Content-Type": [
+                "application/json"
+            ],
+            "Authorization": [
+                "Bearer flat-tropical-vapor"
+            ]
+        },
+        "ResponseHeaders": {
+            "Content-Type": [
+                "application/json"
+            ]
+        },
+        "Method": "POST",
+        "Path": "/api/v1/orders",
+        "QueryParams": {},
+        "StatusCode": 201,
+        "Port": 443,
+        "Timestamp": "2025-09-29T15:18:51.328564007Z",
+        "Scheme": "https"
+    }
+]
+
+
 **IMPORTANT:**
 - WHEN GENERATING TESTS USING TRACE, EXCLUDE THE PATHS THAT ARE NOT API ENDPOINTS.
+- FOR SCENARIO PARSING, ENSURE THAT THE GENERATED REQUEST BODIES IN THE TRACE FILE MATCH THE API SCHEMA.
+- FOR SCENARIO PARSING, ENSURE THAT THE ID FIELDS ARE PROPERLY CHAINED BETWEEN THE REQUESTS AND ALWAYS USE product_id=24. 
+- FOR SCENARIO PARSING, ALWAYS REQUIRE AN API SCHEMA FOR ACCURATE ENDPOINT MAPPING.
+- SCENARIO PARSING ONLY RETURNS JSON ARRAYS - USE OTHER TOOLS FOR ACTUAL TEST GENERATION.
 
 **CRITICAL: SHOW STEPS TO START/STOP PLAYWRIGHT TRACE COLLECTION FOR UI TESTS. NEVER SHOW THE CLI COMMANDS.**
             `,

package/build/services/ModularizationService.js

@@ -1,14 +1,35 @@
-import { getModularizationPrompt, getModularizationPromptForUI, } from "../prompts/modularization-prompts.js";
+import { TestType } from "../types/TestTypes.js";
+import { getModularizationPrompt as getModularizationPromptForUI } from "../prompts/modularization/ui-test-modularization.js";
+import { getModularizationPrompt as getModularizationPromptForIntegration } from "../prompts/modularization/integration-test-modularization.js";
+import { logger } from "../utils/logger.js";
 export class ModularizationService {
-    constructor() { }
     async processModularizationRequest(params) {
+        logger.info("Processing modularization request", {
+            testFile: params.testFile,
+            testType: params.testType,
+            language: params.language,
+        });
+        let prompt = "";
+        const testType = params.testType;
+        switch (testType) {
+            case TestType.UI:
+                prompt = getModularizationPromptForUI(params.testFile);
+                break;
+            case TestType.E2E:
+                prompt = getModularizationPromptForUI(params.testFile);
+                break;
+            case TestType.INTEGRATION:
+                prompt = getModularizationPromptForIntegration(params.testFile);
+                break;
+            default:
+                prompt = "";
+                break;
+        }
         return {
             content: [
                 {
                     type: "text",
-                    text: `${params.testType === "ui"
-                        ? getModularizationPromptForUI(params.testFile, params.language)
-                        : getModularizationPrompt(params.testFile, params.language)}`,
+                    text: prompt,
                 },
             ],
         };