mcpField
B
bootstrap-monorepo

bootstrap-monorepo

github.com/terrylicaDevelopment2126 installsUpdated 1d ago
Repository

About bootstrap-monorepo

bootstrap-monorepo is a skill for bootstrapping single-language and polyglot repositories around moon, proto, Bun, and TypeScript. It guides toolchain pinning, task orchestration, language boundaries, and release setup.

Key features

  1. 01moon task orchestration and caching
  2. 02proto-pinned toolchains
  3. 03Bun and TypeScript control plane
  4. 04Cross-language boundary decision ladder
  5. 05Nx-convergent repository structure
  6. 06Monorepo release configuration

Use cases

  1. 01Starting a new single-language or polyglot repository
  2. 02Running Rust or Python engines behind typed contracts
  3. 03Managing tasks and affected checks with moon
  4. 04Configuring releases for independently versioned projects

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/terrylica/cc-skills --skill bootstrap-monorepo

After installing, type/bootstrap-monorepoin Claude Code to confirm it loaded.

Bundled files

References and scripts installed along with SKILL.md.

references/
bootstrap-monorepo.md
cross-language-interop.md
evolution-log.md
templates/
tsconfig.base.json

Details

From the project README

Bootstrap Polyglot Monorepo (moon + proto + Bun, Nx-convergent)

Canonical reference lives in THIS skill:

→ See: references/bootstrap-monorepo.md → Cross-language boundaries: references/cross-language-interop.md — boundary decision ladder + verified tool status (research-verified 2026-06)

Self-Evolving Skill: This skill improves through use. If instructions are wrong, parameters drifted, or a workaround was needed — fix this file immediately, don't defer. Only update for real, reproducible issues.

When to Use This Skill

Use this skill when:

  • Starting ANY new repository — single-language or polyglot (the structure scales down)
  • Setting up a moon-orchestrated, proto-pinned, Bun/TypeScript-wired monorepo
  • Wiring engines (Rust/Python/Go) behind contracts under a TS control plane
  • You want the repo Nx-convergent from day one (later nx init is mechanical, not a restructure)

Stack

ToolResponsibility
protoToolchain versions (bun, python, rust, node, …) pinned in repo-local .prototools
moonProject graph + task orchestration + caching + affected detection (moon ci)
BunTS runtime for every script, CLI, glue tool, and test; root workspaces
uv / cargoPython / Rust engines invoked natively from moon script: tasks
TypeScriptType-safe control plane (7.0.2+); see TypeScript Configuration below

TypeScript is the control plane; other languages are engines behind language-neutral contracts (JSON Schema 2020-12 / proto) with drift gates and parity tests.

TypeScript Configuration

This skill scaffolds tsconfig.base.json as the canonical reference implementation for all new repositories. Boilerplate path: [templates/tsconfig.base.json](templates/tsconfig.base.json) — the single source of truth for TS7 config shape.

Each new monorepo receives a root tsconfig.base.json with:

  • moduleResolution: bundler, target: ESNext, strict: true, noEmit, skipLibCheck
  • allowImportingTsExtensions, lib: ["ESNext"], verbatimModuleSyntax, noUncheckedIndexedAccess, noImplicitOverride, exactOptionalPropertyTypes
  • types is deliberately omitted from the base — TS7 defaults it to [] (stopping resolution of @types/*, process, JSX globals). Every package declares its own via "types": ["bun"] or ["node"] etc. — bare name only, never @types/bun or bun-types.

Package-level tsconfig.json files extend the base and add their own types array + any legitimate package-specific overrides.

Reference: ~/.claude/typescript-latest-CLAUDE.md (applies estate-wide). Package.json declares "typescript": "latest" (TS7.0.2+).

For TS 7 migration details and per-repo adoption: consult the bootstrapped skill docstrings and the upstream reference.

Language-Selection Default (greenfield tiebreaker)

Choose which language owns the code before choosing how to cross between them. This is a tiebreaker, not a mandate — a SOTA-native ecosystem and existing repo convention override it.

  • TypeScript by default for the control plane: app logic, orchestration, CLIs, APIs, config, validation, agent/workflow automation, and anything future agents must refactor. (TS is structurally typed by default — the most agent-navigable surface.)
  • An engine language only where its ecosystem is SOTA-native: Python for ML/data/science/quant or Python-only libraries; Rust/Go for hot kernels and systems work (Go > Rust as the tiebreaker).
  • Never let an engine language leak across the repo. A Python-only library does NOT make the project Python — wrap it behind ONE typed boundary (ladder below) and keep TS as the public interface. Validate at the boundary: TS types are compile-time only and Python hints are not runtime-enforced.

Crossing a Language Boundary (decision ladder)

When work must cross languages, climb from cheapest to most coupled — stop at the first rung that satisfies the need (full doctrine + verified tool status: references/cross-language-interop.md):

  1. Process boundary — CLI + JSON/NDJSON on stdio (moon script: task). Default.
  2. Schema-typed RPC — protobuf + buf / ConnectRPC, when a long-lived service or stream exists.
  3. Data-plane — Apache Arrow IPC/Flight/ADBC, the moment two languages exchange tables.
  4. In-process FFI — PyO3/maturin, napi-rs, Bun FFI, when call frequency makes 1–3 too slow.
  5. One WASM component core — WIT + Component Model, ONLY if the kernel needs no threads (WASI threading still unshipped as of mid-2026).

Pattern B gate amendment: after the 8-float-op test selects Pattern B, ask "does the kernel need threads?" → if yes, native core (cdylib/PyO3), not WASM.

TypeScript ↔ Python (the most common pair) verified picks, June 2026: rung 1 = Bun.spawn/child_process running Python via uv run, with the version from .python-version (NOT bun:ffi — C-ABI only); rung 2 = FastAPI + @hey-api/openapi-ts (HTTP) or buf-generated protobuf-es + protocolbuffers/python stubs (RPC); schema SSoT = Pydantic v2 → JSON Schema 2020-12 → TS, with a CI drift gate. Full table in the reference.

Quick Commands

# After bootstrap:
moon ci                          # affected quality pipeline
moon run <project>:check         # one project's full gate (lint+test+drift)
moon query projects              # machine-readable project graph (agents read this)
moon query tasks                 # machine-readable task surface
proto use                        # install all .prototools pins on a fresh machine

Legacy Path

Pre-2026-06 repos on Pants + mise (mise is retired; no mise-era reference remains): migrate them onto this stack per-repo (parity-first, cut tasks over one at a time), never big-bang. The old→new mapping is the Migration Map in references/bootstrap-monorepo.md.

Releases (local-first)

Two cases (full recipes in references/bootstrap-monorepo.md Phase 9):

  • One releasable unit → stock semantic-release, one .releaserc.yml, tag v${version}.
  • Multiple independently-versioned projects (the monorepo standard) → per-project namespaced tags (<project>/v${version}) via @rimac-technology/semantic-release-monorepo (stock semantic-release ignores commitPaths — upstream #1279/#1212), selected by a RELEASE_PROFILE-keyed .releaserc.cjs dispatcher that derives each stream's processCommits from its commitPaths, plus a repo-wide umbrella on stock semantic-release. Install the fork with npm i -D --ignore-scripts. Reference impl: example-org/monorepo.

Related Skills

  • itp:semantic-release - Release automation (local-first; Actions only for release/CodeQL/Dependabot/deploy)

Troubleshooting

IssueCauseSolution
proto::detect::failed for moontool installed but no version pinnedproto pin --to global moon <version> (or add to .prototools)
moon not found over sshshims not on non-interactive PATHexport PROTO_HOME + shims PATH in ~/.zshenv (NOT only .zshrc)
Python tests "No module named pytest"uv run prunes dev extrasuv run --extra dev pytest <path> from repo root
PyO3 crate cargo test link errors (_PyBool_Type)tests reference #[pyfunction] under extension-modulekeep logic in pure-Rust core fns; tests call the core, wrapper stays thin
Task runs in wrong cwdscript assumes repo rootoptions: { runFromWorkspaceRoot: true } in the task
Guard task wrongly cachedmoon caches by defaultoptions: { cache: false } on guards/parity/network tasks
Commit "passed" but didn't landa hook auto-fixed files and abortedre-stage and retry; ALWAYS verify git log --oneline -1 after commit

Post-Execution Reflection

After this skill completes, check before closing:

  1. Did the command succeed? — If not, fix the instruction or error table that caused the failure.
  2. Did parameters or output change? — If the underlying tool's interface drifted, update Usage examples and Parameters table to match.
  3. Was a workaround needed? — If you had to improvise (different flags, extra steps), update this SKILL.md so the next invocation doesn't need the same workaround.

Only update if the issue is real and reproducible — not speculative.

Comments

Markdown supported