What this prompt does
This prompt asks the AI to set up a TypeScript monorepo with Turborepo around your chosen [packages], configured so the tooling makes the team faster rather than slower. It produces a root tsconfig.json with project references per package, a shared ESLint and Prettier config package, a shared UI component library using [ui_framework], an internal utility package, a Turbo pipeline for build, test, lint, and type-check, remote caching via [cache_provider], environment handling with @t3-oss/env, Changesets for versioning, a GitHub Actions CI that uses the Turbo cache and tests only affected packages, and per-package Docker builds with production-only dependencies.
The structure works because monorepos succeed or fail on their tooling. Project references and the Turbo pipeline mean a change only rebuilds and retests what it actually affects, and remote caching via [cache_provider] shares that work across machines and CI. The Changesets and affected-only CI steps keep versioning, publishing, and test time from degrading into manual chores as the repo and team grow. The shared ESLint, Prettier, and [ui_framework] packages also give every app one source of truth for style and components, so a fix in the shared library propagates instead of being copy-pasted into each app.
When to use it
- You are consolidating several apps and shared libraries into one repository and want it wired correctly from day one.
- Your existing monorepo rebuilds or retests everything on every change and CI is getting slow.
- You want a shared UI library and shared lint/util packages consumed cleanly across apps.
- You need coordinated versioning and publishing across internal packages via Changesets.
- You want CI to run only the tasks affected by a change, using a shared cache.
- You are onboarding new developers and want a documented, reproducible setup.
Example output
Expect a working monorepo layout: a root config with project references, the turbo.json pipeline, shared config/UI/util packages, Changesets configuration, a GitHub Actions workflow using remote caching and affected-only testing, per-package Dockerfiles, and a README with onboarding steps. It is delivered as an interconnected set of configs and folders rather than one file.
Pro tips
- List
[packages]with their roles (web, api, shared-ui, shared-utils) so the AI sets up the right project references and dependencies between them. - Match
[ui_framework]to what your apps actually use, since the shared component library and its build are tailored to it. - Choose
[cache_provider]based on where you run CI; Vercel Remote Cache and self-hosted caches are configured differently. - Keep shared packages small and focused at first — over-sharing early creates coupling that is hard to untangle later.
- Verify the affected-only CI step against a real change to confirm it skips unrelated packages as intended.
- Iterate by asking it to add a new package and show exactly which configs and references must change to wire it in.
