InsForge Dev

Use this skill set for work inside the InsForge repository.

Then use the narrowest package skill that matches the task:

• backend
• dashboard
• ui
• shared-schemas
• docs

Use the cross-repo release workflow skill when preparing an OSS PR:

• e2e-testing

Core Rules

1. Identify the package boundary before editing.

   • backend/: API, auth, database, providers, realtime, schedules
   • packages/dashboard/: publishable dashboard package that supports self-hosting and cloud-hosting modes
   • frontend/: local React + Vite shell that mounts packages/dashboard/ in self-hosting mode
   • packages/shared-schemas/: cross-package contracts
   • packages/ui/: reusable design-system primitives
   • docs/: product and agent-facing documentation

2. Put code in the narrowest correct layer.

   • Contract change: packages/shared-schemas/ first, then consumers.
   • Backend behavior: route -> service -> provider/infra.
   • Shared dashboard behavior, routes, features, exports, and host contracts: packages/dashboard/.
   • Self-hosting-only bootstrap, env wiring, and shell styling: frontend/.
   • Reusable primitive: packages/ui/ first.

3. Preserve repo conventions.

   • Backend TS source uses ESM-style .js import specifiers.
   • Backend success responses usually return raw JSON, not { data }.
   • Backend validation commonly uses shared Zod schemas plus AppError.
   • Dashboard data access goes through apiClient and React Query.
   • Dashboard frontend tests are split into Vitest unit tests, Vitest component tests, and Playwright UI smoke tests.
   • Shared payloads belong in @insforge/shared-schemas.
   • Never use the TypeScript any type. Prefer precise types, schema-derived types, unknown, or generics.