
Monorepo Navigator
Navigate Turborepo-style monorepos—apps versus packages layouts, dependency rules, affected CI, and Changesets releases—while your agent edits the right workspace.
Overview
Monorepo-navigator is an agent skill most often used in Build (also Ship CI and Operate infra) that explains monorepo layouts, Turborepo pipelines, and release patterns for indie teams.
Install
npx skills add https://github.com/alirezarezvani/claude-skills --skill monorepo-navigatorWhat is this skill?
- Common layouts: apps+packages, domains+shared, and service monorepos with libs
- One-way dependency rules and runtime-free types packages to limit coupling
- Turborepo `turbo.json` pipelines with `dependsOn`, outputs, and env wiring
- Affected-only CI via `--filter` plus remote cache for build and test tasks
- Changesets (or equivalent) for automated, reproducible package publishing
- Documents 3 common monorepo layout patterns (apps+packages, domains+shared, service monorepo)
Adoption & trust: 521 installs on skills.sh; 17.5k GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your agent keeps editing the wrong package, breaking dependency direction, or running full-repo CI because the monorepo conventions were never written down.
Who is it for?
Indie SaaS or multi-package CLI shops adopting or scaling Turborepo with a handful of apps and shared libraries.
Skip if: Single-package repos with no shared libraries, or enterprises needing bespoke Bazel-only governance this skill does not document.
When should I use this skill?
You are designing, refactoring, or debugging monorepo structure, Turborepo pipelines, CI filters, or shared package releases.
What do I get? / Deliverables
You align folder structure, turbo pipelines, and release automation so changes stay scoped, cacheable, and publishable across workspaces.
- Documented repo layout and dependency rules
- turbo.json pipeline configuration guidance
- Release/versioning workflow using Changesets or equivalent
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Build PM is the canonical shelf because structuring apps, packages, and pipelines is foundational product engineering organization before ship hardening. PM covers repo topology, ownership boundaries, and release choreography—not runtime error triage or marketing distribution.
Where it fits
Split a growing Next app into `apps/web` and `packages/ui` with one-way imports documented for the agent.
Configure affected `--filter` CI so pull requests only build touched workspaces before release.
Introduce prerelease Changesets when a shared SDK must ship breaking changes without blocking the main app.
How it compares
Architecture and CI playbook for monorepos—not a substitute for framework-specific frontend or database migration skills.
Common Questions / FAQ
Who is monorepo-navigator for?
Solo builders and tiny teams using Turborepo or similar monorepos who need clear apps-versus-packages rules for agent-assisted refactors.
When should I use monorepo-navigator?
During Build when splitting packages, during Ship when configuring affected CI and turbo pipelines, and during Operate when adjusting release channels for shared libs.
Is monorepo-navigator safe to install?
It is documentation-only; follow the Security Audits panel on this page before trusting any companion scripts in the same repository.
SKILL.md
READMESKILL.md - Monorepo Navigator
# Monorepo Patterns ## Common Layouts ### apps + packages - `apps/*`: deployable applications - `packages/*`: shared libraries, UI kits, utilities - `tooling/*`: lint/build config packages ### domains + shared - `domains/*`: bounded-context product areas - `shared/*`: cross-domain code with strict API contracts ### service monorepo - `services/*`: backend services - `libs/*`: shared service contracts and SDKs ## Dependency Rules - Prefer one-way dependencies from apps/services to packages/libs. - Keep cross-app imports disallowed unless explicitly approved. - Keep `types` packages runtime-free to avoid unexpected coupling. ## Build/CI Patterns - Use affected-only CI (`--filter` or equivalent). - Enable remote cache for build and test tasks. - Split lint/typecheck/test tasks to isolate failures quickly. ## Release Patterns - Use Changesets or equivalent for versioning. - Keep package publishing automated and reproducible. - Use prerelease channels for unstable shared package changes. # monorepo-navigator reference ## Turborepo ### turbo.json pipeline config ```json { "$schema": "https://turbo.build/schema.json", "globalEnv": ["NODE_ENV", "DATABASE_URL"], "pipeline": { "build": { "dependsOn": ["^build"], // build deps first (topological order) "outputs": [".next/**", "dist/**", "build/**"], "env": ["NEXT_PUBLIC_API_URL"] }, "test": { "dependsOn": ["^build"], // need built deps to test "outputs": ["coverage/**"], "cache": true }, "lint": { "outputs": [], "cache": true }, "dev": { "cache": false, // never cache dev servers "persistent": true // long-running process }, "type-check": { "dependsOn": ["^build"], "outputs": [] } } } ``` ### Key commands ```bash # Build everything (respects dependency order) turbo run build # Build only affected packages (requires --filter) turbo run build --filter=...[HEAD^1] # changed since last commit turbo run build --filter=...[main] # changed vs main branch # Test only affected turbo run test --filter=...[HEAD^1] # Run for a specific app and all its dependencies turbo run build --filter=@myorg/web... # Run for a specific package only (no dependencies) turbo run build --filter=@myorg/ui # Dry-run — see what would run without executing turbo run build --dry-run # Enable remote caching (Vercel Remote Cache) turbo login turbo link ``` ### Remote caching setup ```bash # .turbo/config.json (auto-created by turbo link) { "teamid": "team_xxxx", "apiurl": "https://vercel.com" } # Self-hosted cache server (open-source alternative) # Run ducktape/turborepo-remote-cache or Turborepo's official server TURBO_API=http://your-cache-server.internal \ TURBO_TOKEN=your-token \ TURBO_TEAM=your-team \ turbo run build ``` --- ## Nx ### Project graph and affected commands ```bash # Install npx create-nx-workspace@latest my-monorepo # Visualize the project graph (opens browser) nx graph # Show affected packages for the current branch nx affected:graph # Run only affected tests nx affected --target=test # Run only affected builds nx affected --target=build # Run affected with base/head (for CI) nx affected --target=test --base=main --head=HEAD ``` ### nx.json configuration ```json { "$schema": "./node_modules/nx/schemas/nx-schema.json", "targetDefaults": { "build": { "dependsOn": ["^build"], "cache": true }, "test": { "cache": true, "inputs": ["default", "^production"] } }, "namedInputs": { "default": ["{projectRoot}/**/*", "sharedGlobals"], "production": ["default", "!{projectRoot}/**/*.spec.ts", "!{projectRoot}/jest.config.*"], "sharedGlobals": [] }, "parallel": 4, "cacheDirectory": "/tmp/nx-cache" } ``` --- ## pnpm Workspaces ### pnpm-workspace.yaml ```yaml packages: - 'apps/*' - 'packages/*' - 'tools/*' ``` ### workspace:* protocol for local pack