From global-plugin
Use when reviewing a change that crosses service/app boundaries, adds a new top-level package, or shifts dependency direction in the monorepo. Do NOT use for intra-app structure concerns — use nextjs-app-structure-guard or nestjs-service-boundary-guard instead. Covers monorepo ownership, dependency direction, shared-package scope, cross-service contracts.
npx claudepluginhub lgerard314/global-marketplace --plugin global-pluginThis skill is limited to using the following tools:
Keep the monorepo's shape healthy — packages have clear owners, dependencies flow one direction, shared code is stable.
Guides Next.js Cache Components and Partial Prerendering (PPR) with cacheComponents enabled. Implements 'use cache', cacheLife(), cacheTag(), revalidateTag(), static/dynamic optimization, and cache debugging.
Guides building MCP servers enabling LLMs to interact with external services via tools. Covers best practices, TypeScript/Node (MCP SDK), Python (FastMCP).
Share bugs, ideas, or general feedback.
Keep the monorepo's shape healthy — packages have clear owners, dependencies flow one direction, shared code is stable.
index.ts); consumers import from the package root only. — Why: deep imports into internals couple you to implementation details that aren't a stable contract.shared-types (or similarly scoped) package; services never import each other's internal types. — Why: service-to-service type imports hide what is actually a cross-service contract.OWNERS entry (or CODEOWNERS) and a one-paragraph README.md describing its responsibility. — Why: unowned packages become sandboxes where fixes never happen.| Thought | Reality |
|---|---|
| "Just one import from the other app, it's harmless" | That's either a missing shared package or a leak — surface it explicitly instead of hiding it. |
| "The circular dep is tiny, I'll clean it up later" | Tooling breaks silently; later debugging is miserable and the cycle only grows. |
| "I'll flatten the packages for convenience" | Monorepos collapse into spaghetti when boundaries disappear — convenience today is a week of cleanup next quarter. |
Bad:
// apps/web/src/components/UserCard.tsx
import { formatUserName } from '../../admin/src/lib/foo';
Good:
// apps/web/src/components/UserCard.tsx
import { formatUserName } from '@acme/shared-foo';
// apps/admin/src/components/UserCard.tsx
import { formatUserName } from '@acme/shared-foo';
Bad:
import { computeHash } from '@acme/pkg/src/internals/helper';
Good:
import { publicApi } from '@acme/pkg';
The dependency graph has exactly four layers, top to bottom:
apps/*) — Next.js apps, NestJS services, CLI tools. These are the deployable leaves.packages/features/* or packages/<domain>) — domain logic consumed by one or more apps.packages/shared-*, packages/ui, packages/utils) — general-purpose code with no domain opinion.packages/logging, packages/types, packages/config) — zero-dependency primitives every layer can import.Arrows only point downward. An app can import from feature, shared, or foundation. A feature package can import from shared or foundation. A shared package can import from foundation only. Foundation packages import from nothing inside the monorepo.
Detecting a violation. Check package.json dependencies for any entry that names a package above the current layer. Also inspect tsconfig.json references — TypeScript project references ("references": [...]) must follow the same arrow direction; a composite project that references a higher layer is a build-time error waiting to happen.
Introduce a single @acme/contracts (or @acme/shared-types) package at the foundation layer. Place all cross-service DTOs, event payloads, and API response/request types there. Must depend on nothing inside the monorepo (a pure leaf).
Services that currently import from each other (import { CreateOrderDto } from '@acme/order-service/src/...') must be migrated: the DTO moves to @acme/contracts, both services import from there, and the direct service-to-service import is deleted. The HTTP/event contract semantics (versioning, evolution) are the responsibility of integration-contract-safety, not this skill.
Does not duplicate: integration-contract-safety
package.json (name under @acme/ scope prefix), tsconfig.json, and a one-paragraph README.md explaining the package's single responsibility.pnpm-workspace.yaml, packages field in the root package.json, or Turborepo workspaces).CODEOWNERS — one team or one individual, not a catch-all.@acme/feature-<domain> for feature packages, @acme/shared-<name> for shared utilities, no prefix decoration for foundation packages.index.ts only; add an exports field in package.json pointing to the compiled entry."references" entry in each consumer's tsconfig.json and mark the new package's tsconfig.json with "composite": true.Three tools cover cycle detection at different layers:
npx madge --circular --extensions ts packages/ — scans source-level imports and prints every cycle it finds.npx depcruise --validate .dependency-cruiser.js packages/ — enforces declared rules (e.g., "no package may import from an app") and exits non-zero on violation.--build mode: npx tsc --build --dry — when composite projects form a cycle, the compiler refuses to build and reports the loop explicitly; this is the fastest feedback loop in CI.Run all three during a new-package PR and in the pre-merge CI pipeline.
integration-contract-safety's contract-versioning concerns.Produce a markdown report with these sections:
@acme/shared-foo, migrate all consumers, delete the cross-app imports).index.ts; no deep-path imports.