library-architecture

name	library-architecture
description	Plan and review Waitkit library architecture, package boundaries, public exports, TypeScript/tsup output, package metadata, and release impact. Use for API design, package refactors, new package planning, and architecture decisions.

Waitkit Library Architecture

Use this skill to keep Waitkit changes small, framework-agnostic, and safe for published packages.

Repository Shape

• packages/core: current publishable package.
• packages/core/src/index.ts: public API surface.
• packages/core/src/*.ts: internal implementation modules.
• packages/core/tests: Vitest coverage.
• packages/eslint-config and packages/typescript-config: shared tooling.

Decision Rules

• Keep @waitkit/core independent from React, MSW, and CLI concerns.
• Add public exports only when they are intended for consumers.
• Treat exported types, package exports, README examples, and tests as one contract.
• Prefer explicit TypeScript types over inferred public API accidents.
• Avoid broad refactors unless they reduce current complexity or protect a public contract.

Planning Output

For non-trivial changes, produce a short plan with API impact, package boundary impact, files likely to change, tests, and release notes or changeset needs.