Node.js Organizations

Build organizations as a server-enforced authorization boundary, not only a dashboard feature. Prefer the application's existing authentication and database stack.

Confirm before changing

Inspect read-only first. Before writing files, changing schema, adding packages, running migrations, or altering authorization behavior, show a proposal of no more than five short bullets covering the requested organization features, affected areas, permission/tenant model, verification, and anything intentionally excluded. Wait for confirmation, then perform only the approved work. Do not add teams, dynamic roles, billing, or other optional features unless requested. Do not repeat documentation or narrate routine steps unless asked.

Inspect before designing

Inspect authentication, session or token handling, schema, ORM, route authorization, user model, billing ownership, and existing organization code. Preserve the project's framework and database choices.

Implement the organization domain in the Node.js backend itself using its existing route, controller, service, validation, and persistence conventions. Read references/organizations.md before creating the schema or endpoints.

If the project already uses an organization library, including Better Auth's organization plugin, do not build a competing organization system. Preserve that library and apply this skill's tenant-isolation, authorization, lifecycle, and testing requirements around it. Do not migrate authentication providers merely to add organizations.

Model the boundary

Use only concepts the product needs: