Use this skill when setting up or managing monorepos, configuring workspace dependencies, optimizing build caching, or choosing between monorepo tools. Triggers on Turborepo, Nx, Bazel, pnpm workspaces, npm workspaces, yarn workspaces, build pipelines, task orchestration, affected commands, and any task requiring multi-package repository management.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
Use this skill when setting up or managing monorepos, configuring workspace dependencies, optimizing build caching, or choosing between monorepo tools. Triggers on Turborepo, Nx, Bazel, pnpm workspaces, npm workspaces, yarn workspaces, build pipelines, task orchestration, affected commands, and any task requiring multi-package repository management.
When this skill is activated, always start your first response with the 🧢 emoji.
Monorepo Management
A monorepo is a single version-controlled repository that houses multiple
packages or applications sharing common tooling, dependencies, and build
infrastructure. Done well, a monorepo eliminates dependency drift between
packages, enables atomic cross-package changes, and lets you run only the
builds and tests affected by a given change. This skill covers workspace
managers (pnpm, npm, yarn), task orchestrators (Turborepo, Nx), enterprise
build systems (Bazel), internal package patterns, and shared tooling config.
When to use this skill
Trigger this skill when the user:
Wants to set up a new monorepo or migrate from a multi-repo setup
Asks how to configure Turborepo pipelines, caching, or remote caching
Asks how to use Nx projects, affected commands, or the Nx task graph
Needs to share TypeScript, ESLint, or Prettier configs across packages
Asks about pnpm/npm/yarn workspace protocols and dependency hoisting
Wants to implement internal packages with proper bundling and type exports
Needs to choose between Turborepo, Nx, Bazel, or Lerna
Asks about build caching, cache invalidation, or remote cache setup
Do NOT trigger this skill for:
Single-package repository build tooling (Vite, webpack, esbuild) - use the frontend or backend skill
Docker/container orchestration even when containers come from a monorepo
Key principles
Single source of truth - Each config (TypeScript base, ESLint rules,
Prettier) lives in exactly one package and is extended everywhere else.
Duplication is the root cause of config drift.
Explicit dependencies - Every package declares its workspace
dependencies with workspace:*. Never rely on hoisting to make an
undeclared dependency available at runtime.
Cache everything - Every deterministic task should be cached. Define
precise inputs and outputs so the cache is never stale and never
over-broad. Remote caching multiplies this benefit across CI and team.
Affected-only builds - On CI, build and test only the packages that
changed (directly or transitively). Running the full build on every PR
does not scale past ~20 packages.
Consistent tooling - Use the same package manager, Node version, and
task runner across all packages. Mixed tooling creates invisible resolution
differences and breaks cache hits.
Core concepts
Workspace protocols
Protocol
Package manager
Meaning
workspace:*
pnpm
Any version from workspace, keep * in lockfile
workspace:^
pnpm
Resolve range but pin a semver range
*
yarn berry
Any version, resolved from workspace
file:../pkg
npm
Path reference (no lockfile version management)
Task graph
Turborepo and Nx model tasks as a DAG. A build task with
dependsOn: ["^build"] means all dependency packages must complete their
build before the current package starts. This replaces manual ordering scripts.
Remote caching
Remote caches (Vercel, Nx Cloud, S3/GCS) store task outputs keyed by a hash of
inputs. Any machine with the same inputs gets a cache hit and downloads outputs
instead of recomputing. This can reduce CI time by 80-90%.
Affected analysis
Given a diff from a base branch, affected analysis walks the dependency graph in
reverse to find every package that transitively depends on a changed package.
Turborepo: --filter=...[HEAD^1]. Nx: nx affected -t build.
Dependency topology
Packages form a partial order: leaf packages (utils, tokens) have no internal
deps; feature packages depend on leaves; apps depend on features. Circular
dependencies break the DAG and must be detected early.
Common tasks
1. Set up pnpm workspaces
pnpm-workspace.yaml:
packages:-"apps/*"-"packages/*"-"tooling/*"
Root package.json:
{"name":"my-monorepo","private":true,"packageManager":"pnpm@9.4.0","engines":{"node":">=20.0.0","pnpm":">=9.0.0"},"scripts":{"build":"turbo run build","dev":"turbo run dev --parallel","lint":"turbo run lint","test":"turbo run test"},"devDependencies":{"turbo":"^2.0.0"}}
Already on Nx Cloud, need distributed task execution
Nx
Migrating from Lerna
Turborepo (drop-in) or Nx (migration tooling)
Quick rule: Start with Turborepo. Upgrade to Nx when you need project
generators, @nx/enforce-module-boundaries, or Nx Cloud DTE. Only adopt Bazel
for a genuinely polyglot repo with build engineering capacity.
Anti-patterns / common mistakes
Anti-pattern
Problem
Fix
Relying on hoisted node_modules for unlisted deps
Breaks when hoisting changes; silent cross-package contamination
Downstream packages build before deps are ready; missing types/files
Always set ^build dependsOn for build tasks
Circular workspace dependencies
Breaks the task DAG; tools silently skip or hang
Use nx graph or madge to detect; enforce via lint
Publishing internal packages to npm to share within the repo
Introduces a publish cycle where workspace:* suffices
Use workspace protocol; only publish genuinely public packages
Gotchas
Turborepo cache poisoning from over-broad outputs - Setting "outputs": ["**"] in a task caches node_modules/, .git/, and generated files alongside build artifacts. A cache hit then restores stale node_modules from a previous run, causing dependency resolution bugs that are nearly impossible to trace. List only specific artifact directories: dist/**, .next/**, coverage/**.
workspace:* vs workspace:^ produce different lockfile behavior - workspace:* keeps the version as * in the lockfile and always resolves to whatever version the local package is at. workspace:^ pins a semver range at install time. Mixing both across packages in the same repo produces inconsistent resolution and breaks remote cache hits. Choose one convention and enforce it.
Missing "dependsOn": ["^build"] causes type errors in downstream packages - Without this directive, Turborepo may start building a consumer package before its dependency has emitted its dist/ output and type declarations. TypeScript errors like Cannot find module '@myorg/utils' are the symptom. Always declare ^build dependsOn for any task that produces files consumed by other packages.
Nx affected commands use defaultBase which defaults to main but CI often checks out a detached HEAD - nx affected computes affected projects by diffing against defaultBase. In a GitHub Actions PR workflow with actions/checkout@v4, the base branch is not fetched by default. Add fetch-depth: 0 to the checkout step and set --base=origin/main explicitly, or nx affected will compare against nothing and rebuild everything.
Circular workspace dependencies hang builds silently - A circular dependency between packages (A depends on B, B depends on A) breaks the task DAG and causes Turborepo or Nx to either deadlock or skip tasks without error messages. Run nx graph or madge --circular --extensions ts packages/ regularly to detect cycles before they cause build failures in CI.
references/tool-comparison.md - detailed Turborepo vs Nx vs Bazel vs Lerna comparison
Companion check
On first activation of this skill in a conversation: check which companion skills are installed by running ls ~/.claude/skills/ ~/.agent/skills/ ~/.agents/skills/ .claude/skills/ .agent/skills/ .agents/skills/ 2>/dev/null. Compare the results against the recommended_skills field in this file's frontmatter. For any that are missing, mention them once and offer to install:
