Structures and scales JavaScript/TypeScript monorepos with Turborepo, Nx, and pnpm workspaces - layout rules, task pipelines, remote caching, and affected-only CI so build times stay flat as the repo grows. Use when someone asks "should we use a monorepo", "how do I set up Turborepo or Nx", "our monorepo CI takes 40 minutes", "how do I share code between apps", or "why is the cache never hitting". Do NOT use for authoring the CI workflow files themselves - use github-actions instead - and do NOT use for deciding microservice boundaries, which is about runtime architecture, not repo layout - use microservices instead.
Click to play with sound.
---
name: Monorepo Expert
description: Structures and scales JavaScript/TypeScript monorepos with Turborepo, Nx, and pnpm workspaces - layout rules, task pipelines, remote caching, and affected-only CI so build times stay flat as the repo grows. Use when someone asks "should we use a monorepo", "how do I set up Turborepo or Nx", "our monorepo CI takes 40 minutes", "how do I share code between apps", or "why is the cache never hitting". Do NOT use for authoring the CI workflow files themselves - use github-actions instead - and do NOT use for deciding microservice boundaries, which is about runtime architecture, not repo layout - use microservices instead.
---
# Monorepo Expert
A monorepo's promise is shared code with atomic cross-package changes; its failure mode is CI time growing linearly with repo size until every PR waits 40 minutes to test a one-line change. The costly mistake this skill prevents is running every task on every change - the entire discipline of monorepo tooling reduces to one rule: build and test only what the diff affected, and cache everything else.
## Operating procedure
### Step 1: Gather inputs
1. Package manager and tool already in use (pnpm/npm/yarn; Turborepo/Nx/none). Default recommendation for a fresh setup: pnpm + Turborepo for simplicity, Nx when you want generators, enforced boundaries, and plugin depth.
2. Number of apps and packages, and expected growth.
3. Current CI wall-clock time and what a PR actually runs today.
4. Whether builds are reproducible - any task reading undeclared env vars or the network.
5. Team count - boundaries matter more with more teams.
### Step 2: Lay out the repo with a one-way dependency rule
```text
apps/ deployable apps (web, api, mobile)
packages/ shared libraries (ui, config, utils)
```… load the full skill through Skill Me