skills/bun-validator/SKILL.md
Validate Bun workspace configuration and detect common monorepo issues. Ensures proper workspace setup, dependency catalogs, isolated installs, and Bun 1.3+ best practices. Use when setting up a Bun monorepo, before adding workspace dependencies, auditing an existing Bun workspace, or validating package.json in CI.
npx skillsauth add shipshitdev/library bun-validatorInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
python3 scripts/validate.py --root .
python3 scripts/validate.py --root . --strict
# GOOD: v1.3+
bun --version # 1.3.0 or higher
# BAD: v1.2 or earlier
bun --version # 1.2.x
GOOD - Monorepo root:
{
"name": "my-monorepo",
"private": true,
"workspaces": ["apps/*", "packages/*"]
}
BAD - Dependencies in root:
{
"workspaces": ["apps/*"],
"dependencies": {
"react": "^19.0.0" // BAD: Don't put deps in root
}
}
GOOD: See references/full-guide.md (§ Workspace Structure Example) for the full tree — root package.json + bun.lockb, each app/package owns its own package.json.
BAD:
my-monorepo/
├── package.json
├── apps/
│ └── web/
│ ├── package.json
│ └── bun.lockb # BAD: Lockfile in workspace
GOOD - Using workspace protocol:
{
"dependencies": {
"@myorg/ui": "workspace:*",
"@myorg/config": "workspace:^1.0.0"
}
}
BAD - Hardcoded versions:
{
"dependencies": {
"@myorg/ui": "1.0.0" // BAD: Use workspace:*
}
}
GOOD - Centralized versions:
// Root package.json
{
"catalog": {
"react": "^19.0.0",
"typescript": "^5.7.0",
"@types/node": "^22.0.0"
}
}
// apps/web/package.json
{
"dependencies": {
"react": "catalog:" // Uses version from catalog
}
}
GOOD - Default in Bun 1.3: Packages can only access dependencies they explicitly declare.
BAD - Hoisted dependencies:
// Don't disable isolation
{
"workspaces": {
"packages": ["apps/*"],
"nohoist": ["**"] // Don't do this
}
}
See § Dependency Catalogs (Bun 1.3+) above for the catalog syntax.
bun update --interactive # Selectively update deps
bun why react # Explain why a package is installed
# Install in specific workspace
bun add express --cwd apps/api
# Run script in workspace
bun run --cwd apps/web dev
# Run in all workspaces
bun run --filter '*' build
Cause: Dependency not declared in workspace package.json
Fix:
bun add <package> --cwd <workspace>
Cause: Running bun install in workspace directory
Fix:
rm apps/*/bun.lockb packages/*/bun.lockb
bun install # From root only
Cause: Same package with different versions across workspaces
Fix: Use dependency catalogs:
{
"catalog": {
"problematic-package": "^1.0.0"
}
}
See references/full-guide.md (§ Validation Output Example) for a sample report.
"@myorg/shared": "workspace:*"--cwd for workspace operations: bun add lodash --cwd apps/web (not cd apps/web && bun add)bun install only from the root — keep a single lockfile# .github/workflows/validate.yml
- name: Validate Bun Workspace
run: |
python3 scripts/validate.py \
--root . \
--strict \
--ci
linter-formatter-init - Sets up Biome with Bunproject-init-orchestrator - Creates workspace structurenextjs-validator - Validates Next.js in workspacedevelopment
Coordinates a weekly engineering review of board accuracy, recent code changes, operational health, and scoped cleanup. Use for a recurring repository health review or a review of the last several days.
testing
Audits project board configuration and prepares explicitly requested setup, copy, or normalization changes while preserving the existing workflow and provider boundaries. Use when inspecting a board's fields, columns, scope, or configuration.
testing
Reconciles a project board with current work and delivery evidence, reports incomplete coverage and metadata gaps, and applies only approved provider-supported field changes. Use when auditing board drift, reviewing blocked work, or assessing upcoming delivery.
development
Walk through how a subsystem works. Use for "how does X work", code walkthroughs before changing something, and placement or ownership questions. Explains architecture, runtime flow, and onboarding mental models. Can critique architecture. Use why for motivation.