| 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.
