docs(skill): recommend standalone Studio over embedded for Next.js

[joneidejohnsen]

Summary

• Flips the Next.js architecture recommendation from embedded Studio to a standalone Studio in a simple monorepo layout (studio/ + web/), aligning the skill with the new onboarding flow.
• Documents why standalone wins: sanity dev/sanity build run on Vite (10-30x faster than compiling the Studio through next dev/next build), Studio auto-updates only work standalone (Next.js does not support ESM with import maps), TypeGen watch mode only works with sanity dev, and a separate Studio keeps the content model from becoming website-centric.
• nextjs.md: standalone Studio is now Option A with rationale and CORS setup; the embedded Studio setup section is replaced with standalone setup plus migration steps for existing embedded Studios.
• project-structure.md: monorepo (no workspace tooling required) is now the recommended structure with a frontend; embedded Studio demoted to a legacy note.
• get-started.md: Studio creation now uses --output-path studio from the repo root with an explicit warning not to run the CLI inside a Next.js app (it switches to the embedded flow); the Next.js scaffold lands in web/ alongside it.
• typegen.md, visual-editing.md, SKILL.md: monorepo TypeGen config is the primary example, the Presentation previewUrl snippet gains the origin required for standalone Studios, and quick-reference descriptions drop embedded Studio.

Test plan

• Review rendered markdown for the six touched files
• Sanity-check the standalone Studio CLI command (npm create sanity@latest -- ... --output-path studio) against the current CLI behavior
• Confirm the onboarding agent prompt ("getting-started reference") now produces a standalone studio/ + web/ layout when followed end-to-end

Made with Cursor

[jwoods02]

Looks good, definitely improvement but still doesn't give good instructions for what to do if an agent runs inside an existing nextjs app instead of in a parent folder to be able to do the side by side setup.

EDIT: I've taken another look at this in the context of the getting started guide also. I think this can be merged as is, but I would think about following with an escape hatch for users running this in an existing app folder, either tell the skill to return and tell the user to run again in a different folder or propose a different solution, right now the agent might guess

[mwritter]

I think this looks good - it should be enough to steer the agent in the right direction

[stipsan]

sanity.config.ts, unless I'm wrong, has to be top-level next to package.json. It should only be in a studio/ folder, if that folder has studio/package.json

[stipsan]

Suggesting a /studio subfolder isn't a clean or equivalent alternative to embeddable studios. The subfolder approach is a bit of untested territory and the safest approach is to co-locate and use the same package.json, but not create any /app/studio/[...splat]/page.tsx routes.
We can and should have a convention where studio code like schemas live in a subfolder, if we use sanity/studio for it then it becomes a natural fit for functions, where you may have sanity/functions/sync-tag-invalidate too. The /app might also setup sanity live in sanity/live.ts.

In any case sanity.config.ts, sanity.cli.ts etc etc must be in the same folder as the package.json installing them. And we shouldn't direct the agent to suddenly create a second package.json as that is the poor mans monorepo, and often won't work with vercel deployments (while the colocated approach can work by changing the build command to for example next build && sanity build --out /studio and have a vercel.json that sets up url rewrites for /studio to the static build).