PreviousNext

Structure

How the monorepo is organized and where to implement each concern.

What It Does

The repository separates runtime apps from reusable feature kits and shared configuration packages.

When To Use

  • You need to locate the correct ownership boundary before editing code.
  • You are adding a feature and must decide app-level vs shared-level changes.

Prerequisites

  • Basic Turborepo/pnpm workspace familiarity.

How To Use

Use this mapping to decide where code should live.

Monorepo Snapshot

package.json
turbo.json
AreaPurpose
apps/*Product entrypoints (dashboard, marketing, mobile, api, docs site)
kit/*Reusable business capabilities (auth, settings, org, billing, etc.)
packages/sharedApp-shared config and glue (@kit/shared)
supabase/*Database schemas, generated app schemas, migrations, SQL tests
cli/*Project generation and feature-pruning automation

Package Snapshot

package.json

Typical implementation flow:

  1. Define shared schema/config in packages/shared or app config.
  2. Register filters in app lib/init-server-filters.ts / init-cross-env-filters.ts.
  3. Consume functionality in app routes/components.

MCP Context

capability: repo_navigation entrypoints: - apps/ - kit/ - packages/shared/ - supabase/ - cli/ inputs: - feature_request outputs: - target_edit_locations constraints: - prefer kit reuse over app duplication - keep app-level code focused on composition/configuration side_effects: - none

Agent Recipe

  1. Identify which runtime app is affected.
  2. Check whether a kit/* module already owns the behavior.
  3. Apply changes in the shared layer first, then app integration points.

Troubleshooting

  • If an import path starts with @kit/shared/*, source files live under packages/shared/src/*.
  • If a feature works in one app and not another, compare filter initialization files.

How is this guide?

Last updated on 3/23/2026