What this prompt does
This prompt designs a monorepo structure for a project with [package_count] packages ([package_list]), using [monorepo_tool] for workspace management. It defines a shared dependency hoisting strategy, selective CI that only tests and builds changed packages and their dependents, a versioning strategy ([version_strategy]), root-level shared configuration for ESLint, TypeScript, and Prettier, internal package linking without publishing, and Docker build optimization with per-package layer caching. It also specifies developer commands like bootstrap, clean, test-affected, and build-all.
The structure works because it directly targets what makes monorepos either fast or miserable. Selective CI that rebuilds only affected packages, combined with good dependency hoisting, keeps a growing monorepo from turning every small change into a full rebuild. By asking for the full directory layout and root configuration files like turbo.json, the prompt produces a concrete starting point rather than abstract architecture advice. It also handles internal package linking without publishing, so shared packages like shared-ui and shared-utils can be consumed by apps without a release cycle, and it defines developer commands such as bootstrap, clean, test-affected, and build-all. Those scripts matter because a monorepo's ergonomics live or die on whether everyday tasks are a single command or a fragile sequence of manual steps.
When to use it
- Your project has grown shared packages that several apps depend on (
[package_list]). - You want
[monorepo_tool]set up with a sensible workspace and hoisting strategy. - Full rebuilds on every change are slowing you down and you need selective, affected-only CI.
- You need a clear
[version_strategy]across[package_count]packages. - You want shared ESLint, TypeScript, and Prettier config managed at the root.
- You want Docker builds optimized with per-package layer caching.
Example output
Expect a concrete monorepo blueprint: a full directory structure for your [package_list], root configuration files such as package.json and turbo.json, a dependency hoisting strategy, selective CI configuration that builds only affected packages, a [version_strategy] setup, internal linking guidance, Docker layer-caching configuration per package, and developer scripts for bootstrap, clean, test-affected, and build-all. The output is meant to be copied into a real repository, so expect concrete file contents rather than prose describing what the config should contain.
Pro tips
- List your real packages in
[package_list]so the directory structure and internal linking reflect your actual dependency graph. - Choose
[monorepo_tool]to match your ecosystem; the generated config (turbo.json, workspace settings) is tool-specific. - Lean into the selective CI configuration, because affected-only builds are the single biggest factor keeping a monorepo fast.
- Pick
[version_strategy]based on your release reality; independent versioning with changesets suits packages that ship separately. - Get dependency hoisting right early, since fixing it later means untangling many package.json files at once.
- Iterate by adding a new package to
[package_list]and asking it to update the structure and affected-build configuration accordingly.
