root-package-json-config

Configure and audit root package.json files for MetaSaver monorepos.

Updated Aug 23, 2026
One-click install
npx skills add https://github.com/metasaver/claude-marketplace --skill root-package-json-config
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: root-package-json-config
Source: https://github.com/metasaver/claude-marketplace/tree/main/plugins/metasaver-core/skills/config/workspace/root-package-json-config
Command: npx skills add https://github.com/metasaver/claude-marketplace --skill root-package-json-config

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill standardizes and audits the root package.json of MetaSaver monorepos to ensure consistent workspace configuration, required scripts (build, dev, lint, test, format, clean), turbo pipeline setup, an explicit packageManager field, and the rule that only devDependencies exist at root (no runtime dependencies except cross-platform binaries).

Core Features & Use Cases

  • Monorepo metadata: enforces name: "@metasaver/*", private: true, packageManager, engines, and module type.
  • Standard scripts: ensures a comprehensive set of scripts (build, clean, dev, lint, prettier, test, db, docker, setup).
  • DevDependencies-only tooling: validates tooling lives in devDependencies only.
  • Workspace configuration: uses pnpm-workspace.yaml in place of a workspaces field.
  • Cross-platform binaries: places turbo-linux-64 and turbo-windows-64 in dependencies.

Quick Start

Use this skill to generate and validate a templates/root-package.json.template and audit the repository's root package.json for conformance.

Frequently Asked Questions about root-package-json-config

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I standardize root package.json configuration for a pnpm monorepo?

Standardizing root package.json enforces consistent monorepo metadata, required scripts, and dependency policies across workspaces. This Skill applies a template that enforces the five standards: monorepo metadata (@metasaver/* namespace, private flag, packageManager field), 18 required scripts (build, dev, lint, test, format, clean, and others), devDependencies-only tooling, pnpm-workspace.yaml instead of a workspaces field, and cross-platform binaries like turbo-linux-64 and turbo-windows-64 in dependencies.

What scripts and dependencies should a root package.json contain in a monorepo?

A standardized root package.json requires exactly 18 scripts covering build, clean, dev, lint, prettier, test, db, docker, and setup tasks, plus turbo pipeline orchestration. Only devDependencies are permitted at root (tooling, linters, formatters), except cross-platform binaries in dependencies. Runtime dependencies must live in individual workspace packages.

Why use pnpm-workspace.yaml instead of a workspaces field in root package.json?

Using pnpm-workspace.yaml instead of a workspaces field in root package.json provides explicit, dedicated workspace configuration separate from package metadata. This enforces the MetaSaver standard and works with pnpm's native workspace resolution, reducing duplication and improving clarity in monorepo structure.

Can I audit an existing root package.json against monorepo standards?

Yes. This Skill validates conformance against the five root package.json standards: monorepo metadata (name, private, packageManager, engines, module type), all 18 required scripts, devDependencies-only policy, absence of a workspaces field, and presence of cross-platform binaries. Use it to identify missing or misconfigured entries.

What metadata fields are required in a MetaSaver monorepo root package.json?

Required metadata includes name (@metasaver/* format), private: true, an explicit packageManager field (pnpm version), engines specification, and module type declaration. These fields establish monorepo identity and ensure consistent tooling across all workspaces.

Do I need cross-platform binary packages in a monorepo root package.json?

Yes, if using turbo for pipeline orchestration. Cross-platform binaries like turbo-linux-64 and turbo-windows-64 must be placed in root dependencies (not devDependencies) to ensure turbo CLI availability across Linux and Windows environments without workspace installation.