3. Project Architecture & Directory Roles
Top-Level Directory Structure
Layer Responsibilities
packages/common/ — Shared Kit (Internal Only, Not Published to npm)
Explicitly excluded via !packages/common in pnpm workspace. Handled via noExternal: /^@common$/ in tsup config, bundling it into each package at build time.
packages/core/ — @julong/mono-rele2-core
packages/utils/ — @julong/mono-rele2-utils
apps/site/ — Rspress Documentation Site
package-docs-plugin scans packages/*/README.md to generate dynamic pages at /packages/<name> routes and automatically renders a package list table on the /packages overview page.
Data Flow
tsconfig path alias: @common → ../common/index.ts (configured in each package's tsconfig.json)
Architecture Diagrams
Package & Dependency Structure
packages/commonis excluded from the workspace and never published — it is inlined into each package at build time.
Per-Package Internal Structure (utils example)
A single tools definition is consumed three ways: the MCP server (stdio), the CLI runner, and documentation/skill generation.
Build & Documentation Generation Flow
Release Pipeline (.github/workflows/release.yml)
Separation of Concerns
- Tool definitions reside in each package's
src/tools/— business logic lives only here - Common MCP server/CLI logic lives in
packages/common/kit/— server creation, CLI parsing, error handling - Shared config files live in
packages/common/build/— tsup config, README generation script - Each package's
src/server.tsis a thin layer that passes tool objects tocreateMcpServer() - Each package's
src/cli.tsis a thin layer that passes tool objects torunCli()
Adding New Features
- New MCP server package: Create
packages/<name>/directory, define tools insrc/tools/*.ts - New tool in existing package: Add a file under the package's
src/tools/(or add to an existing file) - New shared functionality: Add a module under
packages/common/kit/ - Build config changes: Modify
packages/common/build/tsup.config.mjs