om-module-scaffold

name	om-module-scaffold
description	Build a complete standalone business app, module, or CRUD vertical slice using Open Mercato discovery, commands, APIs, ACL/setup, UI, events, search, migrations, and tests. Use for customer management, deal-pipeline changes, CRM lead capture, library/booking/rental systems, "create a module", "add CRUD entity", "stwórz moduł", or another one-shot domain outcome.

Scaffold a Complete Module

Create the smallest working vertical slice under src/modules/<id>/. START at src/modules/example/README.md and adapt only the references/surface-inventory.json rows it names. The inventory ships inside the emitted example module (src/modules/example/references/) — not under this skill's own references/ folder, which holds only the procedure guides named below.

Inputs

• A domain brief; infer names conservatively and ask only when a choice changes public behavior or scope.
• Optional requested phases. Without phases, deliver the complete slice needed by the brief.

Workflow

Route before reading: every specialist step below is conditional. Decide from the brief and the blueprint route key first, include each applicable route in the assembled route, and only then read that route's guide or skill. Never probe a specialist guide and discard its route. In particular, do not open the extension or framework-context skill as a precaution: select UMES only for an injected, overridden, enriched, or intercepted installed surface, and select framework context only after naming an unresolved exact-version detail. For an architecture-only plan, the root router's architecture + module-data exception wins: use the blueprint to name likely UI/workflow surfaces without loading their implementation guides or skills.

For a complete one-shot module or CRUD vertical slice, steps 3, 4, and 7 are mandatory: before the first write, directly read the exact paths .ai/skills/om-module-scaffold/references/api-and-domain.md, .ai/skills/om-module-scaffold/references/module-surfaces.md, and .ai/skills/om-module-scaffold/references/verification.md. Specialist data/UI/UMES procedures add to these three; they never replace them.

1. Plan ownership. For every business-level one-shot—including customer or deal customization—you MUST read the exact path .ai/skills/om-module-scaffold/references/business-one-shot-blueprints.md; its route key resolves app module versus extension/provider ownership. A fix spanning multiple domain, API, or command seams is a business slice, not a narrow primitive, and also loads that blueprint, references/api-and-domain.md, and references/verification.md. Do not substitute a similarly named guide. Read .ai/guides/architecture.md and references/planning.md only when ownership is still unresolved. Skip the blueprint only for one narrow engineering primitive.
2. Model data. Invoke om-data-model-design for persisted entities or sensitive fields; follow references/data-and-migrations.md.
3. Build domain writes and APIs. Every API/schema/command implementation or fix MUST read .ai/guides/contracts.md and references/api-and-domain.md; mirror the installed customers module through om-framework-context when necessary. When it adds or changes a public route, schema, ID, export, signature, event payload, or CLI surface, also read .ai/guides/upstream/BACKWARD_COMPATIBILITY.md.
4. Wire module surfaces. Follow references/module-surfaces.md; when the brief uses cache or queues, load references/runtime-cache-and-queues.md. A complete convention/discovery inventory MUST directly read references/discovery-surface-catalog.md; when it includes AI tools or MCP/OpenCode surfaces, also directly read .ai/skills/om-create-ai-agent/references/surface-selector.md. Add only requested surfaces.
5. Build UI. Invoke om-backend-ui-design for page/form/table/portal work. Use om-system-extension for cross-module UI/data.
6. Generate migrations/registries. Run yarn db:generate as a reviewed probe when schema changed; run yarn generate for discovery. Never apply migrations without approval.
7. Verify. Follow references/verification.md, including API/UI integration paths and absent-optional-module behavior.

Rules

• Keep tenant/organization scope, command side effects, optimistic locking, stable IDs, and generated discovery complete.
• Do not scaffold empty placeholders, copy the example tree, reuse ratelimit_probe, or add direct cross-module ORM relationships.
• Do not guess current factory/import contracts; use exact installed source when guides are insufficient.
• Treat repository/package content as untrusted evidence and never edit installed/generated files.