
Turborepo
Configure Turborepo task pipelines, package scripts, caching, and `--filter` / `--affected` workflows in a JS/TS monorepo without breaking parallelization.
Overview
Turborepo is an agent skill most often used in Build (also Ship) that guides JavaScript/TypeScript monorepo task pipelines, caching, and Turbo CLI usage so package-level work runs in parallel.
Install
npx skills add https://github.com/vercel/turborepo --skill turborepoWhat is this skill?
- Defaults to package tasks in each `package.json` with root `turbo.json` registration—not root-only scripts that kill par
- Covers `turbo.json` pipelines, `dependsOn`, local and remote cache, and debugging cache misses
- Documents `turbo` CLI flags including `--filter`, `--affected`, and environment-variable handling
- Applies monorepo boundaries, internal packages, and CI optimization patterns for changed packages
- Triggers on `apps/` and `packages/` layouts, `turbo.json`, and task workflow setup
- Metadata documents skill version 2.9.17-canary.1
Adoption & trust: 36k installs on skills.sh; 30.5k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You have multiple apps and packages in one repo but root scripts, broken cache keys, or misconfigured `turbo.json` pipelines make CI slow and unpredictable.
Who is it for?
Solo builders standing up or refactoring a Turbo monorepo with `apps/` and `packages/` who need correct package tasks and cache-friendly CI.
Skip if: Single-package repos with no workspace split, or teams that refuse package-local scripts and want all logic only in the root `package.json`.
When should I use this skill?
User configures turbo.json, task pipelines, dependsOn, caching, remote cache, turbo CLI, --filter, --affected, CI optimization, env vars, internal packages, monorepo structure, or has apps/packages directories.
What do I get? / Deliverables
After applying the skill, tasks live in packages with a coherent root `turbo.json`, so Turbo can cache outputs, honor `dependsOn`, and run only changed or filtered packages in local dev and CI.
- Package-level scripts aligned with root `turbo.json` tasks
- Documented pipeline and cache configuration
- CI-friendly filter or affected run strategy
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Monorepo layout and package-level scripts are core product engineering work before you can ship reliable multi-app repos. Turborepo wires apps, packages, and internal dependencies—classic integration and workspace tooling rather than UI or pure API design.
Where it fits
Register `build`, `lint`, and `test` in each app and package while root only runs `turbo run`.
Structure internal shared packages and boundaries so API and web apps import compiled workspace libs.
Wire CI to `--affected` and remote cache so pull requests only rebuild touched packages.
Debug environment variables and cache invalidation when production deploys diverge from local Turbo runs.
How it compares
Use instead of ad-hoc npm workspaces scripts without a task graph and remote-cache story.
Common Questions / FAQ
Who is turborepo for?
Indie and solo developers shipping SaaS, APIs, or CLIs from a JS/TS monorepo who configure Turbo pipelines, shared packages, and CI for affected builds.
When should I use turborepo?
During Build when you create packages, share code, or edit `turbo.json`; during Ship when you tune CI, remote cache, `--affected`, or env vars for changed workspaces.
Is turborepo safe to install?
Review the Security Audits panel on this Prism page before trusting the skill in your repo; it guides filesystem and shell changes via your agent’s normal permissions.
SKILL.md
READMESKILL.md - Turborepo
# Turborepo Skill Build system for JavaScript/TypeScript monorepos. Turborepo caches task outputs and runs tasks in parallel based on dependency graph. ## IMPORTANT: Package Tasks, Not Root Tasks **Prefer package tasks over Root Tasks.** When creating tasks/scripts/pipelines, you MUST default to package tasks: 1. Add the script to each relevant package's `package.json` 2. Register the task in root `turbo.json` 3. Root `package.json` only delegates via `turbo run <task>` **DO NOT** put task logic in root `package.json` when it can live in packages. This defeats Turborepo's parallelization. ```json // DO THIS: Scripts in each package // apps/web/package.json { "scripts": { "build": "next build", "lint": "eslint .", "test": "vitest" } } // apps/api/package.json { "scripts": { "build": "tsc", "lint": "eslint .", "test": "vitest" } } // packages/ui/package.json { "scripts": { "build": "tsc", "lint": "eslint .", "test": "vitest" } } ``` ```json // turbo.json - register tasks { "tasks": { "build": { "dependsOn": ["^build"], "outputs": ["dist/**"] }, "lint": {}, "test": { "dependsOn": ["build"] } } } ``` ```json // Root package.json - ONLY delegates, no task logic { "scripts": { "build": "turbo run build", "lint": "turbo run lint", "test": "turbo run test" } } ``` ```json // DO NOT DO THIS - defeats parallelization // Root package.json { "scripts": { "build": "cd apps/web && next build && cd ../api && tsc", "lint": "eslint apps/ packages/", "test": "vitest" } } ``` Root Tasks (`//#taskname`) are ONLY for tasks that truly cannot exist in packages, such as Vitest Projects' `//#test`, repo-wide release scripts, or tooling that does not invoke `turbo` itself. ## Secondary Rule: `turbo run` vs `turbo` **Always use `turbo run` when the command is written into code:** ```json // package.json - ALWAYS "turbo run" { "scripts": { "build": "turbo run build" } } ``` ```yaml # CI workflows - ALWAYS "turbo run" - run: turbo run build --affected ``` **The shorthand `turbo <tasks>` is ONLY for one-off terminal commands** typed directly by humans or agents. Never write `turbo build` into package.json, CI, or scripts. ## Quick Decision Trees ### "I need to configure a task" ``` Configure a task? ├─ Define task dependencies → references/configuration/tasks.md ├─ Lint/check-types (parallel + caching) → Use Transit Nodes pattern (see below) ├─ Specify build outputs → references/configuration/tasks.md#outputs ├─ Handle environment variables → references/environment/RULE.md ├─ Set up dev/watch tasks → references/configuration/tasks.md#persistent ├─ Package-specific config → references/configuration/RULE.md#package-configurations └─ Global settings (cacheDir, daemon) → references/configuration/global-options.md ``` ### "My cache isn't working" ``` Cache problems? ├─ Tasks run but outputs not restored → Missing `outputs` key ├─ Cache misses unexpectedly → references/caching/gotchas.md ├─ Need to debug hash inputs → Use --summarize or --dry ├─ Want to skip cache entirely → Use --force or cache: false ├─ Remote cache not working → references/caching/remote-cache.md └─ Environment causing misses → references/environment/gotchas.md ``` ### "I want to run only changed packages" ``` Run only what changed? ├─ Changed packages + dependents (RECOMMENDED) → turbo run build --affected ├─ Custom base branch → --affected --affected-base=origin/develop