What this prompt does
This prompt casts the AI as a React Server Components architect and walks it through migrating a [project_type] app to RSC. It starts by auditing the component tree in [source_directory], classifying every component as a server-component candidate or a client-component requirement, then designs a clean server/client boundary for [primary_feature] that cuts the client bundle by at least [target_reduction]. The classification table is where most teams trip, so the prompt front-loads it.
The structure works because RSC migrations fail at the boundary. After classification, it replaces useEffect + fetch patterns with direct async server-component fetching for each endpoint under [api_base_url], designs serializable prop interfaces so non-serializable values never cross the boundary, sets up error.tsx error boundaries per route segment, and ends with a performance checklist measuring bundle size, TTFB, and LCP against the [target_reduction] goal. That final measurement keeps the migration honest. By converting useEffect + fetch patterns into direct async server-component fetching for each endpoint under [api_base_url], it removes a whole class of client-side loading code and moves data fetching closer to the source. The serializable-prop interface design is deliberate, because functions and class instances cannot cross the server/client boundary, and getting that wrong is one of the most common ways an RSC migration breaks. Pairing Suspense with error.tsx boundaries per route segment means a slow or failed server fetch degrades gracefully instead of blanking the page.
When to use it
- You are moving a client-heavy React dashboard or app onto Server Components
- You need a component-by-component classification of server vs client
- You want to replace useEffect data fetching with async server components
- You keep accidentally passing functions or class instances across the boundary
- You need route-segment error boundaries via the error.tsx convention
- You want measured proof that the client bundle actually shrank
Example output
The AI returns a classification table (Component, Current Type, Recommended Type, Reason), a server/client boundary strategy for [primary_feature] with "use client" placement, before/after code for converting useEffect + fetch to async server-component fetching across [api_base_url], serializable prop interface designs, error.tsx error boundaries per route segment with client-side ErrorBoundary wrappers, and a performance validation checklist measuring bundle reduction, TTFB, and LCP toward [target_reduction].
Pro tips
- Trust the classification table — anything using hooks, event handlers, or browser APIs must stay a client component
- Design serializable props deliberately; functions and class instances cannot cross the server/client boundary
- Push
"use client"as far down the tree as possible so the smallest subtree ships to the browser - Convert data fetching one endpoint at a time under
[api_base_url]so a regression is easy to isolate - Measure the bundle before and after against
[target_reduction]; an unmeasured migration tends to drift - Pair Suspense boundaries with error boundaries so a slow or failed server fetch never blanks the route
