npm-package-starter

name	npm-package-starter
description	Create a new TypeScript npm package project, or assess an existing npm package project for alignment with this starter.
argument-hint	<create|scaffold|update|sync> [package-name]

npm-package-starter

Use this skill for npm package starter work. The first argument should choose the workflow.

Contract

• create or scaffold: create a new TypeScript npm package project. Read scaffold.md.
• update or sync: assess an existing npm package project and prepare a sync plan. Read sync.md.
• If the first argument is missing or ambiguous, stop and ask the user to choose one of those workflows. Do not infer the workflow from a package name or directory name.

Blocks

Blocks are reusable project slices used by both workflows. Each block owns one concern, such as the package skeleton, runtime setup, or linting setup. The scaffold workflow applies selected blocks to create a project; the sync workflow compares an existing project against the same blocks to describe drift.

The starter defines a ready-to-publish TypeScript package setup with build, test, lint, release, and CI wired together. The default setup is Bun and Biome. Node.js/pnpm, ESLint, and PostgreSQL-in-CI are supported variants with their own starter blocks, so existing projects can be assessed or updated without forcing a full migration to the default stack.

The block files live under blocks/ in this skill directory. Treat them as the source of truth.

Block	Purpose
base/	Shared package skeleton and baseline defaults
runtime/bun/	Bun runtime for development and testing
runtime/pnpm/	Node/pnpm runtime for development and testing
linting/biome/	Biome linting and formatting
linting/eslint/	ESLint linting and formatting
ci/postgres/	PostgreSQL service for GitHub Actions tests

Block rules

• Resolve block paths relative to this SKILL.md.
• Copy full files as-is.
• When a block ships a fragment for an existing file, merge it into the file with the same path.
• When merging block fragments, preserve applicable comments from the blocks. Treat those comments as semantic documentation, not formatting noise.
• Use each block's BLOCK.md as local notes for that block.
• Preserve project-specific customizations when assessing existing projects.
• Stop if a required block or fragment is missing.