om-trim-unused-modules

name: om-trim-unused-modules description: Propose disabling modules in src/modules.ts that the current standalone project does not actually use. Intended to be offered after the user adds a new custom module, because a fresh create-mercato-app scaffold enables every built-in module (classic mode) and that is rarely what the project actually needs in production.

Trim Unused Modules

A fresh create-mercato-app scaffold enables every built-in Open Mercato module by default (classic mode) so that the app "just works" on day one. Once the user has added a new custom module and knows what they actually want to build, many of those defaults are dead weight — they slow down yarn dev, pollute the navigation sidebar, pull in unnecessary dependencies, and show the user features that will confuse their end users.

Invoke this skill when:

• The user just added a new module to src/modules.ts via yarn mercato module add … or by hand-creating src/modules/<name>/.
• The user asks "which modules do I really need?" or "how do I slim down the app?"
• You notice during another task that src/modules.ts still has every built-in module enabled AND the user's business domain clearly does not need some of them (e.g. a blog-only app with sales, catalog, currencies, workflows, integrations, data_sync all active).

Workflow

1. Never disable modules silently. Always confirm with the user via AskUserQuestion before editing src/modules.ts.

2. Read the current module list. Parse src/modules.ts. For each entry:

   • Record the module id and its source (@open-mercato/core, @open-mercato/<package>, @app).
   • Flag entries with from: '@app' as user modules — never propose disabling these.
   • Flag entries with from: '@open-mercato/…' as built-in modules — eligible for review.

3. Gather usage signals. For each built-in module, check:

   • Is the module's feature ID referenced in src/modules/**/acl.ts or src/modules/**/setup.ts?
   • Is a type/name from the module imported anywhere in src/**?
   • Does any subscriber/worker declaration in src/modules/** reference an event ID the module owns?
   • Does the backend sidebar config reference routes from the module?
   • Is the module listed as a hard dependency in any enabled integration provider's manifest? Record yes/no per signal. If ALL signals return "no", mark the module as a removal candidate.

4. Mark hard-required modules. Never propose disabling modules that other parts of the framework rely on by convention. The baseline set that should stay enabled in almost every project:

   • auth, customer_accounts, entities, configs, organizations, tenants, users Include any module that another enabled module's setup.ts declares as a dependency.

5. Present the proposal. Use AskUserQuestion with a multi-select list of removal candidates. Include:

   • The module ID and a one-line description of what it does.
   • Which usage signals came back negative.
   • Whether disabling it will require running DB operations (e.g. dropping its tables — NOT something this skill performs; flag it so the user knows).

6. Apply the user's choices. For each module the user confirms:

   • Remove the entry from src/modules.ts.
   • Do NOT delete files from node_modules/@open-mercato/* (packages stay installed — disabling just means the app no longer loads them).
   • Do NOT drop the module's database tables. Data removal is a separate, destructive operation that the user must request explicitly.
   • If dashboards is one of the disabled modules, you MUST also update src/app/(backend)/backend/page.tsx so it no longer renders <DashboardScreen />. Replace the body with a redirect(...) to the first backend page the user can reach — prefer the main sidebar group (e.g. /backend/customers/people) and fall back to /backend/profile if nothing else is enabled. Without this edit, /backend will crash at build or request time because the removed module no longer ships DashboardScreen. Commit this edit in the same change as the src/modules.ts edit.

7. Re-run the generator. After the edit:

   yarn generate
   

   This regenerates .mercato/generated/* without the disabled modules and triggers the best-effort structural cache purge.

8. Report. Print a short summary:

   • Which modules were disabled.
   • Which modules were kept (and the signal that kept each).
   • Reminder that package dependencies are still installed and module tables still exist; if the user wants to fully remove a module, they must uninstall the package and manually drop its tables.

Constraints

• NEVER remove a from: '@app' entry.
• NEVER remove auth, customer_accounts, entities, configs, organizations, tenants, or users.
• NEVER delete files from node_modules/ or from src/modules/<mod>/ on behalf of the user — only edit src/modules.ts.
• NEVER drop database tables.
• If the user answers "no" to every removal candidate, exit quietly and note that classic mode is preserved.

When NOT to run this skill

• In a monorepo development environment (apps/mercato/src/modules.ts) — the monorepo deliberately keeps every module enabled for framework development.
• On an imported ready app (--app or --app-url) — those snapshots are curated by their authors.
• During a yarn dev run — disabling modules while the server is live can cause transient errors. Ask the user to stop yarn dev, run the skill, then restart.