// Add a new subpath export to the @cyanheads/mcp-ts-core package. Use when creating a new public API surface that consumers import from a dedicated subpath (e.g., @cyanheads/mcp-ts-core/newutil).
| name | add-export |
| description | Add a new subpath export to the @cyanheads/mcp-ts-core package. Use when creating a new public API surface that consumers import from a dedicated subpath (e.g., @cyanheads/mcp-ts-core/newutil). |
| metadata | {"author":"cyanheads","version":"1.1","audience":"internal","type":"reference"} |
Subpath exports are defined in package.json under the exports field. Each subpath maps to a source entry point that gets compiled to dist/. The exports catalog in CLAUDE.md/AGENTS.md must stay in sync with package.json.
The build uses tsconfig.build.json (not tsconfig.json) with rootDir: ./src and include: ["src/**/*"]. This means every source file at src/foo/bar.ts compiles to dist/foo/bar.js — the dist/ path in each export entry must match wherever tsc produces the compiled output for the named source file. Choose your source file location to produce the dist/ path you want in the export entry.
Create the entry point source file under src/ (e.g., src/utils/new-util.ts)
Add the subpath to package.json exports, mirroring the source path:
// source: src/utils/new-util.ts → dist: dist/utils/new-util.js
"./newutil": {
"types": "./dist/utils/new-util.d.ts",
"import": "./dist/utils/new-util.js"
}
Update the exports catalog in both CLAUDE.md and AGENTS.md — add a row to the table. These files must stay byte-identical; the simplest approach is cp CLAUDE.md AGENTS.md after editing
Build with bun run build to generate dist/ output
Verify the export resolves through the package's exports map:
# Confirm the compiled file exists at the expected dist path
ls dist/utils/new-util.js
# Confirm the subpath export resolves correctly (tests the exports map, not just the dist file)
bun -e "import('@cyanheads/mcp-ts-core/newutil').then(m => console.log(Object.keys(m)))"
Run bun run devcheck to verify
| Convention | Rule |
|---|---|
| Subpath | all-lowercase, no underscores (e.g., utils, storage/types, testing/fuzz) |
| Source file | kebab-case (e.g., error-handler.ts) |
| Export name | camelCase for values, PascalCase for types |
package.json exports with types and import conditionsCLAUDE.md and AGENTS.md (must be byte-identical)peerDependencies and peerDependenciesMeta in package.jsonbun run build succeedsdist/ path and subpath import resolves correctlytests/integration/package-consumer.int.test.ts updated: new subpath added to the import spec list and toHaveLength count incrementedbun run devcheck passesLand working-tree changes as logical commits — the work grouped by concern, topped by a release commit (version bump, changelog, regenerated artifacts) and an annotated tag. Verify, commit, tag. Stops at "committed and tagged locally" — no push, no publish. The release-and-publish skill picks up from here. Distilled from the git_wrapup_instructions protocol.
Pick and run a multi-phase workflow that chains foundational task skills (`git-wrapup`, `release-and-publish`, `maintenance`, `field-test`, `setup`, etc.) end-to-end. Routes user intent to a workflow file under `workflows/` — greenfield builds, maintenance + release, field-test + fix, or known-work + release. Single source for the universal rules (no commits without authorization, no destructive git, no marketing language), the orchestrator posture (own the goal, ground sub-agents in primary sources, verify against the goal), and the sub-agent strategy (orient block, parallel fanout, isolation, normalization) that apply across every workflow. Sub-agents are an optional capability — workflows run linearly when fanout isn't available.
Scaffold an MCP App tool + UI resource pair. Use when the user asks to add a tool with interactive UI, create an MCP App, or build a visual/interactive tool.
Scaffold a new service integration. Use when the user asks to add a service, integrate an external API, or create a reusable domain module with its own initialization and state.
Finalize documentation and project metadata for a ship-ready MCP server. Use after implementation is complete, tests pass, and devcheck is clean. Safe to run at any stage — each step checks current state and only acts on what still needs work.
Post-init orientation for an MCP server built on @cyanheads/mcp-ts-core. Use after running `@cyanheads/mcp-ts-core init` to understand the project structure, conventions, and skill sync model. Also use when onboarding to an existing project for the first time.