export function getModularizationPrompt(filePath) {
    return `# INTEGRATION TEST MODULARIZATION - SIMPLE AND SAFE

**CRITICAL: Use the 'write' tool to save the modularized code to: ${filePath}**
**DO NOT use search_replace - use the 'write' tool to overwrite the entire file with the modularized version**

**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. **NEVER GENERALIZE SELECTORS** - Keep all selectors/locators exactly as they are in the original code (do not refactor into dynamic template strings)
4. **NO LOGIC CHANGES** - Do not modify conditions, validations, or assertions
5. **NO DATA CHANGES** - Do not change any request/response values or expected results
6. **PRESERVE PATH PARAMETERS** - API path parameters must be passed as function parameters
7. **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:**
Generalizing or refactoring selectors into dynamic templates
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.`;
}
