monorepo-orchestration-setup
Skill4 starsChanged 10 months agoMITView on GitHub
Use when setting up or orchestrating monorepos with build tools like Nx, Turborepo, or Lerna. Covers workspace configuration, task pipelines, dependency graph management, caching strategies, and CI/CD integration patterns.
In this repository67 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- agents-onboardingSkill
- agent-workitem-automationSkill
- architecture-testingSkill
- aspire-integration-testingSkill
- automated-standards-enforcementSkill
- best-practice-introductionSkill
- branching-strategy-and-conventionsSkill
- broken-windowSkill
- change-risk-rollbackSkill
- ci-cd-conformanceSkill
- component-boundary-ownershipSkill
- contract-consistency-validationSkill
- csharp-best-practicesSkill
- deployment-provenanceSkill
- documentation-as-codeSkill
- documentation-scaffoldSkill
- dotnet-bespoke-code-minimisationSkill
- dotnet-best-practicesSkill
- dotnet-domain-primitivesSkill
- dotnet-efcore-practicesSkill
- dotnet-healthchecksSkill
- dotnet-logging-serilogSkill
- dotnet-mapping-standardSkill
- dotnet-open-source-first-governanceSkill
- dotnet-source-generation-firstSkill
- dotnet-specification-patternSkill
- dotnet-testing-assertionsSkill
- environment-traceabilitySkill
- finishing-a-development-branch-iddSkill
- greenfield-baselineSkill
- impacted-scope-enforcementSkill
- incremental-change-impactSkill
- incremental-deploymentSkill
- innersource-governance-bootstrapSkill
- issue-driven-deliverySkill
- library-extraction-stabilisationSkill
- local-dev-experienceSkill
- markdown-authorSkill
- modern-csharp-coding-standardsSkill
- observability-logging-baselineSkill
- pair-programmingSkill
- persona-switchingSkill
- process-skill-routerSkill
- quality-gate-enforcementSkill
- release-tagging-planSkill
- repo-best-practices-bootstrapSkill
- repository-foundation-bootstrapSkill
- requirements-gatheringSkill
- runtime-tooling-validationSkill
- safe-brownfield-refactorSkill
- scoped-colocationSkill
- security-processesSkill
- selective-build-testSkill
- semantic-version-impactSkill
- session-awareSkill
- skills-first-workflowSkill
- static-analysis-securitySkill
- structured-review-workflowSkill
- The first 60 shown.
The file
We split this skill into the rules it gives an agent
9 rules. About 0 are common, 9 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈9
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 31
Before creating new monorepo configuration, check for existing setup:
- Distinctive: line 47
Use existing tool conventions
- Distinctive: line 53
Create minimal initial configuration
- Distinctive: line 54
Document tool selection in ADR
- Distinctive: line 80
Prefer flexibility over structure
- Distinctive: line 180
Run only affected projects in CI:
- Distinctive: line 229
Solution: Use affected commands with base branch comparison.
- Distinctive: line 234
Before declaring setup complete, verify:
- Distinctive: line 316
walking-skeleton-delivery: Use monorepo structure for E2E skeleton across services
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Monorepo Orchestration Setup
Overview
Configure and orchestrate monorepos for scalable multi-project development. This skill covers workspace setup, task pipeline configuration, incremental builds, and CI/CD integration using modern monorepo tooling (Nx, Turborepo, Lerna).
REQUIRED: superpowers:verification-before-completion
When to Use
- Setting up a new monorepo from scratch
- Migrating from polyrepo to monorepo architecture
- Adding monorepo tooling (Nx, Turborepo, Lerna) to existing repository
- Configuring task pipelines and build orchestration
- Optimising build performance with caching strategies
- Setting up CI/CD for monorepo workflows
- User asks about "workspace configuration" or "multi-package repository"
Detection and Deference
Before creating new monorepo configuration, check for existing setup:
# Check for existing monorepo tools
ls nx.json turbo.json lerna.json pnpm-workspace.yaml 2>/dev/null
# Check for existing workspace configuration
ls package.json && grep -l "workspaces" package.json 2>/dev/null
# Check for existing project structure
ls packages/ apps/ libs/ projects/ 2>/dev/nullIf existing configuration found:
- Build upon existing monorepo setup
- Use existing tool conventions
- Reference existing workspace structure
If no configuration found:
- Help select appropriate monorepo tool
- Create minimal initial configuration
- Document tool selection in ADR
Tool Selection Guide
Select monorepo tooling based on ecosystem and requirements:
| Tool | Best For | Key Features |
| Nx | Large enterprise, full-stack | Plugins, generators, affected graph |
| Turborepo | JavaScript/TypeScript focused | Simple config, fast caching |
| Lerna | npm package publishing | Version management, publishing |
Selection Criteria
Choose Nx when:
- Building full-stack applications (frontend + backend)
- Need code generators and scaffolding
- Require advanced dependency graph analysis
- Team benefits from opinionated structure
Choose Turborepo when:
- Primary focus is JavaScript/TypeScript
- Want minimal configuration overhead
- Need fast remote caching
- Prefer flexibility over structure
Choose Lerna when:
- Managing multiple npm packages for publishing
- Need version synchronisation across packages
- Publishing to npm registry is primary goal
- Already using Lerna (migration cost consideration)
Core Workflow
- Assess requirements (team size, project types, CI/CD needs)
- Select monorepo tool based on ecosystem and requirements
- Configure workspace with appropriate project structure
- Define task pipelines (build, test, lint dependencies)
- Enable caching (local and remote)
- Configure CI/CD with affected-only execution
- Document conventions and onboarding guide
Configuration Patterns
Workspace Structure
Standard monorepo directory layout:
monorepo/
apps/ # Deployable applications
web/
api/
packages/ # Shared libraries
ui/
utils/
tools/ # Build tooling and scripts
nx.json # or turbo.json
package.json # Root package with workspacesTask Pipeline Configuration
Define task dependencies to enable incremental builds:
Nx (nx.json):
{
"targetDefaults": {
"build": {
"dependsOn": ["^build"],
"cache": true
},
"test": {
"dependsOn": ["build"],
"cache": true
},
"lint": {
"cache": true
}
}
}Turborepo (turbo.json):
{
"tasks": {
"build": {
"dependsOn": ["^build"],
"outputs": ["dist/**"]
},
"test": {
"dependsOn": ["build"],
"outputs": []
},
"lint": {
"outputs": []
}
}
}Caching Strategies
Enable caching for reproducible, fast builds:
Local caching:
- Enabled by default in Nx and Turborepo
- Cache stored in
.nx/cacheornode_modules/.cache/turbo - Clear with
nx resetorturbo run build --force
Remote caching:
- Nx Cloud:
npx nx connect - Vercel Remote Cache:
turbo loginandturbo link - Self-hosted: Configure cache storage endpoint
CI/CD Integration
Run only affected projects in CI:
GitHub Actions (Nx):
- name: Build affected
run: npx nx affected -t build --base=origin/main
- name: Test affected
run: npx nx affected -t test --base=origin/mainGitHub Actions (Turborepo):
- name: Build
run: npx turbo run build --filter=...[origin/main]
- name: Test
run: npx turbo run test --filter=...[origin/main]Common Pitfalls
Pitfall 1: Over-coupling packages
Problem: Too many dependencies between packages slow builds.
Solution: Design packages with clear boundaries. Use dependency graph visualisation
to identify problematic coupling (nx graph or turbo run build --graph).
Pitfall 2: Missing task dependencies
Problem: Tasks run in wrong order causing failures.
Solution: Explicitly define dependsOn for all tasks that require outputs from
other tasks. Test with clean cache.
Pitfall 3: Cache invalidation issues
Problem: Stale cache causes incorrect builds.
Solution: Define all outputs and inputs correctly. Use hashing configuration to include all relevant files. When in doubt, clear cache and rebuild.
Pitfall 4: Slow CI without affected filtering
Problem: CI rebuilds everything on every commit.
Solution: Use affected commands with base branch comparison. Configure proper base branch for PRs and main branch builds.
Verification Checklist
Before declaring setup complete, verify:
- Workspace configuration is valid (
nx show projectsorturbo run build --dry-run) - Task pipelines execute in correct order
- Caching works correctly (second run is fast)
- Affected detection works (only changed projects run)
- CI/CD pipeline executes affected tasks only
- Team onboarding documentation exists
- Architecture decision documented (tool selection rationale)
Quick Reference Commands
Nx
# Create workspace
npx create-nx-workspace@latest myworkspace
# Generate application
npx nx g @nx/web:app myapp
# Generate library
npx nx g @nx/js:lib mylib
# Run affected
npx nx affected -t build test lint
# Visualise dependency graph
npx nx graphTurborepo
# Create workspace
npx create-turbo@latest
# Run all builds
npx turbo run build
# Run affected builds
npx turbo run build --filter=...[origin/main]
# Visualise dependency graph
npx turbo run build --graphLerna
# Initialise Lerna
npx lerna init
# Bootstrap packages
npx lerna bootstrap
# Run script in all packages
npx lerna run build
# Run only in changed packages
npx lerna run build --since main
# Version and publish
npx lerna version
npx lerna publishRed Flags - STOP
These statements indicate monorepo anti-patterns:
| Thought | Reality |
| "Everything in one repo is simpler" | Without proper tooling, monorepos become unmanageable; use orchestration |
| "We don't need affected detection" | Full builds on every commit waste CI time exponentially; enable filtering |
| "Caching isn't worth the setup" | Remote caching can reduce build times by 70%+; invest in setup |
| "Packages can depend on anything" | Unconstrained coupling kills build performance; define boundaries |
| "We'll optimise builds later" | Build performance debt compounds quickly; configure pipelines early |
| "Task ordering doesn't matter" | Missing dependencies cause flaky builds; explicitly define dependsOn |
Integration with Other Skills
- walking-skeleton-delivery: Use monorepo structure for E2E skeleton across services
- ci-cd-conformance: Configure CI/CD pipelines with affected-only execution
- automated-standards-enforcement: Apply linting and formatting across all packages
Evidence Examples
Nx Graph Output
npx nx graph --file=output.jsonSample output.json (dependency graph):
{
"graph": {
"nodes": {
"web": {
"name": "web",
"type": "app",
"data": { "root": "apps/web" }
},
"api": {
"name": "api",
"type": "app",
"data": { "root": "apps/api" }
},
"ui": {
"name": "ui",
"type": "lib",
"data": { "root": "packages/ui" }
},
"utils": {
"name": "utils",
"type": "lib",
"data": { "root": "packages/utils" }
}
},
"dependencies": {
"web": [
{ "source": "web", "target": "ui", "type": "static" },
{ "source": "web", "target": "utils", "type": "static" }
],
"api": [{ "source": "api", "target": "utils", "type": "static" }],
"ui": [{ "source": "ui", "target": "utils", "type": "static" }],
"utils": []
}
}
}Turborepo Graph Output
$ npx turbo run build --graph=graph.html
# Or JSON format:
$ npx turbo run build --graph=graph.jsonSample turbo output (task execution):
• Packages in scope: @myorg/api, @myorg/ui, @myorg/utils, @myorg/web
• Running build in 4 packages
• Remote caching disabled
@myorg/utils:build: cache hit, replaying output
@myorg/ui:build: cache miss, executing
@myorg/api:build: cache hit, replaying output
@myorg/web:build: cache miss, executing
Tasks: 4 successful, 4 total
Cached: 2 cached, 4 total
Time: 3.245sAffected Detection Evidence
# Nx affected output
$ npx nx affected:apps --base=main --head=HEAD
> NX Affected apps:
- web
$ npx nx affected:libs --base=main --head=HEAD
> NX Affected libs:
- ui
- utils
# Turborepo affected output
$ npx turbo run build --filter='...[origin/main]' --dry-run
• Packages in scope: @myorg/ui, @myorg/web
• Running build in 2 packages
• 2 packages in graph are affected by changesBaseline Performance Metrics
Metrics to Capture
| Metric | Description | Target |
| Cold build time | Full build with empty cache | Baseline |
| Warm build time | Full build with populated cache | < 10% of cold |
| Affected build time | Build only changed packages | < 30% of cold |
| Cache hit rate | Percentage of cached tasks | > 80% in CI |
Performance Worksheet
# Monorepo Performance Baseline
**Repository**: [repo-name]
**Date**: YYYY-MM-DD
**Tool**: [Nx/Turborepo/Lerna]
**Packages**: [N] apps, [M] libs
## Build Performance
| Scenario | Time | Cache Status | Notes |
| ---------------- | ---- | ------------ | -------------------------------------- |
| Cold build (all) | [X]s | No cache | `nx run-many -t build --skip-nx-cache` |
| Warm build (all) | [X]s | Full cache | Second run of above |
| Affected (1 lib) | [X]s | Partial | After changing utils |
| Affected (1 app) | [X]s | Partial | After changing web only |
## CI Performance
| Metric | Before Optimization | After | Improvement |
| ------------------ | ------------------- | ----- | ----------- |
| Average PR build | [X]m | [Y]m | [Z]% |
| Cache hit rate | [X]% | [Y]% | +[Z]% |
| Affected detection | [X]s | [Y]s | [Z]% |
## Verification Commands
# Measure cold build
time npx nx run-many -t build --skip-nx-cache
# Measure warm build (run twice, take second)
npx nx run-many -t build
time npx nx run-many -t build
# Measure affected build
git checkout -b test-affected
echo "// change" >> packages/utils/src/index.ts
time npx nx affected -t build --base=main
git checkout main && git branch -D test-affected
# Check cache statistics (Nx)
npx nx show cache-stats
# Check cache statistics (Turborepo)
npx turbo run build --summarizeSample CI Evidence
# GitHub Actions summary output
Build Summary:
Total packages: 12
Affected packages: 3
Cached tasks: 9/12 (75%)
Build time: 45s (vs 180s full build)
Cache savings: 135s (75% reduction)Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

