monorepo
Standardizes monorepo operations like builds, tests, and package scaffolding across the codebase.
Install
mkdir -p .claude/skills/monorepo && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/6267" && unzip -o skill.zip -d .claude/skills/monorepo && rm skill.zipInstalls to .claude/skills/monorepo
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Monorepo scripts, package boilerplate, conventions. Use when: "how do I run", "bun run", "build this", "run tests", "typecheck", "create a new package", linting, scaffolding packages.Key capabilities
- →Fix formatting and linting
- →Run type checking
- →Execute unit tests and benchmarks
- →Scaffold new packages
How it works
It uses consistent script naming conventions and workspace filtering to execute tasks across the monorepo from the root directory.
Inputs & outputs
When to use monorepo
- →Run monorepo tests
- →Type-check the entire project
- →Scaffold a new package
- →Run linting scripts
About this skill
Script Commands
The monorepo uses consistent script naming conventions.
Commands
| Command | Purpose | When to use |
|---|---|---|
bun format | Fix formatting (biome) | Development |
bun format:check | Check formatting | CI |
bun lint | Fix lint issues (biome) | Development |
bun lint:check | Check lint issues | CI |
bun typecheck | Type checking (tsc, svelte-check, astro check) | Both |
bun test | Run unit tests (*.test.ts only) | Both |
bun bench | Run benchmarks (*.bench.ts; reports, no assertions) | Manual |
Convention
- No suffix = fix (modifies files)
:checksuffix = check only (for CI, no modifications)typecheckalone = type checking (separate concern, cannot auto-fix)testruns only*.test.ts;benchruns only*.bench.ts. A file is one or the other : never both. Benchmarks print reports; tests assert.
Dev Scripts
Start apps from the repo root, not by cd-ing into the app. Root
bun dev:<app> runs every process the app needs; for apps that talk to the
hosted API (honeycrisp, vocab, whispering, and the
api dashboard), it also starts @epicenter/api on localhost:8787 via
bun run --filter. Root bun dev:<app>:ui runs the app's frontend
alone when that split exists; for Tauri apps, it maps to the package's
dev:web. bun dev:api runs just the backend. Local Books, Local Mail, and
Super Chat have their own multi-process flows documented in their READMEs;
they have no root dev:* target.
Inside a single package, the conventions are:
Non-Tauri apps use a single dev script that runs the underlying tool
directly (vite dev, astro dev, wrangler dev). Tauri desktop apps
(honeycrisp, whispering, matter) have two dev surfaces and name them
explicitly: dev launches the desktop shell (aliasing dev:desktop), and
dev:web runs Vite alone, which each app's tauri.conf.json invokes as its
beforeDevCommand. The suffix convention applies primarily to database
commands:
| Script | Meaning |
|---|---|
dev | The default local workflow. May still require Infisical login for app secrets (e.g. API keys), but only ever talks to local infrastructure at runtime. |
dev:web | Tauri apps: the Vite dev server alone, no desktop shell. Invoked by tauri.conf.json as beforeDevCommand. |
dev:desktop | Tauri apps: launches the native desktop app (tauri dev). dev aliases this. |
db:*:local | Runs against local Postgres. Works without Infisical login. |
db:*:remote | Wraps with infisical run --env=prod. Production data; treat as admin. |
There is no dev:remote. Production data is reached only through :remote db
scripts and deploy, never through a development server.
After Completing Code Changes
Run type checking to verify:
bun typecheck
This runs bun run --filter '*' typecheck which executes the typecheck script in each package (e.g., tsc --noEmit, svelte-check).
New Package Boilerplate
When creating a new package in packages/, follow this exact structure.
package.json
{
"name": "@epicenter/<package-name>",
"version": "0.0.1",
"exports": {
".": "./src/index.ts"
},
"license": "AGPL-3.0-or-later",
"scripts": {
"typecheck": "tsc --noEmit"
},
"dependencies": {},
"devDependencies": {
"@types/bun": "catalog:",
"typescript": "catalog:"
}
}
Key conventions:
exportsonly, nomain/types: modern resolvers ignoremain/typeswhenexportsis present. The entry point is./src/index.ts; there is no build step, consumers import the source directly.- Use
"workspace:*"for internal deps (e.g.,"@epicenter/workspace": "workspace:*"). - Use
"catalog:"for shared versions managed in the rootpackage.jsoncatalogs. peerDependenciesfor packages consumers must also install (e.g.,yjs).license: defaultAGPL-3.0-or-later(everything Epicenter ships or runs). UseMITonly if the package is meant for third-party developers to embed in their own software (the toolkit). Seedocs/licensing/licensing-strategy.md;bun run check:licensesfails if an MIT package can reach an AGPL one.
tsconfig.json
A leaf config picks a tier and adds nothing that repeats a base. For a Bun library:
{
"extends": "../../tsconfig.base.json",
"compilerOptions": {
"types": ["bun"],
"noUnusedLocals": true,
"noUnusedParameters": true
}
}
A Svelte or browser library extends ../../tsconfig.dom.json instead. For all eight leaf tiers, the never-redeclare list, and the module strategy, see the tsconfig skill.
After creating the package, run bun install from the repo root to register it in the workspace.
When not to use it
- →When running dev scripts inside sub-packages instead of the root
Prerequisites
Limitations
- →Benchmarks and tests cannot be in the same file
- →Production data is restricted to specific remote scripts
How it compares
It provides a centralized, consistent command interface for all packages rather than individual package-level scripts.
Compared to similar skills
monorepo side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| monorepo (this skill) | 1 | 3mo | Review | Intermediate |
| turborepo | 61 | 3mo | Review | Intermediate |
| run-nx-generator | 5 | 4mo | Review | Intermediate |
| upgrading-expo | 3 | 5mo | Review | Intermediate |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by EpicenterHQ
View all by EpicenterHQ →You might also like
turborepo
vercel
Turborepo monorepo build system guidance. Triggers on: turbo.json, task pipelines, dependsOn, caching, remote cache, the "turbo" CLI, --filter, --affected, CI optimization, environment variables, internal packages, monorepo structure/best practices, and boundaries. Use when user: configures tasks/workflows/pipelines, creates packages, sets up monorepo, shares code between apps, runs changed/affected packages, debugs cache, or has apps/packages directories.
run-nx-generator
nrwl
Run Nx generators with prioritization for workspace-plugin generators. Use this when generating code, scaffolding new features, or automating repetitive tasks in the monorepo.
upgrading-expo
sickn33
Upgrade Expo SDK versions
dependency-upgrade
wshobson
Manage major dependency version upgrades with compatibility analysis, staged rollout, and comprehensive testing. Use when upgrading framework versions, updating major dependencies, or managing breaking changes in libraries.
codex-skill
feiskyer
Use when user asks to leverage codex, gpt-5, or gpt-5.1 to implement something (usually implement a plan or feature designed by Claude). Provides non-interactive automation mode for hands-off task execution without approval prompts.
nx-workspace-patterns
wshobson
Configure and optimize Nx monorepo workspaces. Use when setting up Nx, configuring project boundaries, optimizing build caching, or implementing affected commands.