prettier

docs/references/nextjs/auth.mdx

@@ -223,4 +223,4 @@ export default async function Page() {
     </>
   )
 }
-```
+```

docs/references/nextjs/nextjs15clerkprovider.mdx

@@ -2,6 +2,7 @@
 title: 'Nextjs 15 `<ClerkProvider>`'
 description: Access minimal authentication data for managing sessions and data fetching.
 ---
+
 Partial prerendering (PPR) is a new rendering mode for Next.js that allows a page to be both static _and_ dynamic. To accomplish this, Next.js analyzes your pages and determines which parts of the page can be statically rendered at build-time, and which parts rely on dynamic request data. This allows granular optimization at the component level, instead of at the page level.
 
 Historically, usage of `<ClerkProvider>` has opted your entire application in to dynamic rendering due to the dynamic and personalized nature of auth-related data. We've heard the feedback from our users that this default didn't feel like it aligned with Next.js best practices. Starting with v6, **`<ClerkProvider>` will no longer opt your entire application into dynamic rendering by default.** This sets the stage for PPR support and more granular optimization.
@@ -44,4 +45,4 @@ export default function RootLayout({ children }) {
 }
 ```
 
-`<ClerkProvider>` was also refactored to support PPR out of the box, even in dynamic mode. When `dynamic` is passed to the provider, every page is opted-in to PPR when enabled. For this reason, it is still recommended to take a more granular approach to dynamic data access.
+`<ClerkProvider>` was also refactored to support PPR out of the box, even in dynamic mode. When `dynamic` is passed to the provider, every page is opted-in to PPR when enabled. For this reason, it is still recommended to take a more granular approach to dynamic data access.