Use this agent when you need to standardize API response formats across microservices to ensure consistent contract between backend and frontend. This agent should be invoked when:\n\n1. **Detecting Response Inconsistencies**: When you notice different services returning different response structures (e.g., `{ applications, total }` vs `{ success, data, total }`)\n\n2. **Implementing New Endpoints**: Before creating new API endpoints to ensure they follow the standard response format from the start\n\n3. **Frontend Integration Issues**: When the frontend reports unexpected response structures or missing fields like `success`, `data`, or `timestamp`\n\n4. **API Contract Violations**: When services return raw arrays/objects instead of wrapped responses with metadata\n\n5. **Error Response Standardization**: When error responses lack consistent structure (`success: false`, `error`, `errorCode`, `timestamp`)\n\n**Examples of when to use this agent:**\n\n<example>\nContext: User is working on the Application Service and notices inconsistent response format.\n\nuser: "I'm getting applications from the API but the response structure doesn't match what the dashboard service returns. Can you help?"\n\nassistant: "I notice the Application Service is returning `{ applications, total, page, limit }` instead of the standardized format. Let me use the api-response-standardizer agent to fix this inconsistency."\n\n<uses Task tool to launch api-response-standardizer agent>\n\n<commentary>\nThe agent will analyze mock-application-service.js, create utils/response.js helper, refactor all endpoints to use the standard format `{ success, data, total, page, limit, totalPages, timestamp }`, and provide diffs with before/after examples.\n</commentary>\n</example>\n\n<example>\nContext: User is implementing a new Guardian Service endpoint.\n\nuser: "I need to add a new endpoint GET /api/guardians/:id that returns a single guardian"\n\nassistant: "Before implementing this endpoint, let me use the api-response-standardizer agent to ensure it follows the project's standard response format."\n\n<uses Task tool to launch api-response-standardizer agent>\n\n<commentary>\nThe agent will provide the correct response wrapper: `{ success: true, data: guardianObject, timestamp }` and ensure consistency with other services.\n</commentary>\n</example>\n\n<example>\nContext: User reports frontend errors when consuming User Service API.\n\nuser: "The frontend is breaking when trying to display users. The dataAdapter expects a 'data' field but it's not there."\n\nassistant: "This is a response format inconsistency. Let me use the api-response-standardizer agent to standardize the User Service responses and update the dataAdapter if needed."\n\n<uses Task tool to launch api-response-standardizer agent>\n\n<commentary>\nThe agent will refactor mock-user-service.js to return `{ success, data: users, total, page, limit, totalPages, timestamp }` instead of `{ users, total }`, and update dataAdapter.ts to consume the new format.\n</commentary>\n</example>\n\n<example>\nContext: Developer is reviewing code and notices error responses are inconsistent.\n\nuser: "Some endpoints return just error messages as strings, others return objects. This needs to be standardized."\n\nassistant: "You're right, error responses need standardization. Let me use the api-response-standardizer agent to implement consistent error handling across all services."\n\n<uses Task tool to launch api-response-standardizer agent>\n\n<commentary>\nThe agent will create a fail() helper that returns `{ success: false, error, errorCode, details, timestamp }` and refactor all error handlers to use this format.\n</commentary>\n</example>\n\n**Proactive Usage**: This agent should be used proactively when:\n- Adding new microservices to ensure they follow the standard from day one\n- During code reviews when response format inconsistencies are spotted\n- Before major frontend refactoring to ensure clean contracts\n- When updating INTEGRATION_GUIDE.md or API documentation