Cabloy Domain Planning

Cabloy Domain Planning

Use this skill when the user is still deciding how to name and structure a new business domain.

Goals

1. detect whether the active repository is Cabloy Basic or Cabloy Start
2. classify the request as domain planning rather than immediate scaffolding
3. default to suite-first planning for real business domains
4. propose valid providerId, suite, and module names before any generation happens
5. require explicit confirmation before handing off to scaffold commands
6. always keep a custom naming path available for the user
7. finish with the CLI-first next step and matching verification guidance

Step 1: Detect edition first

Check the repository root for these marker files:

• __CABLOY_BASIC__
• __CABLOY_START__

Interpretation:

• only __CABLOY_BASIC__ present → this is Cabloy Basic
• only __CABLOY_START__ present → this is Cabloy Start
• both markers present → treat the repository as ambiguous or invalid and stop before making edition-specific assumptions
• neither marker present → inspect the owning package scripts and nearby repository structure, then ask before making an edition-specific assumption

This matters most when examples, frontend flavors, or suite/module availability may differ between editions.

Step 2: Confirm that this is a planning request

Use this skill when the user is asking things such as:

• how to plan a new CRM, OA, training, ERP, or similar business area
• whether the work should start as a suite or only a module
• how to choose providerId, suiteName, or first module names
• whether a proposed name is valid
• which naming option should be preferred before scaffolding

Do not use this skill once naming is already confirmed and the request is clearly about backend or frontend scaffolding. In that case, route to the appropriate scaffold skill.

Step 3: Default to suite-first planning

For real business work, prefer the suite-first path described in:

• repo-docs/fullstack/suites-and-modules.md

Use this practical rule:

• prefer a suite for the business domain boundary
• prefer modules for the capabilities inside that domain
• treat a standalone module as the exception for very small, disposable, or tutorial-only work

Do not jump into :create:module first when the real question is still the domain boundary.

Step 4: Collect or infer the planning inputs

Before proposing names, determine these inputs:

1. the business domain term
   • examples: crm, oa, training
2. whether the user already has a required namespace or provider prefix
   • examples: demo, biz, mycorp
3. whether the work is backend-only, frontend-only, or fullstack
4. whether the user wants a conservative functional naming style or a custom/branded naming style

If the user already provides names, validate them instead of replacing them silently.

Step 5: Validate the naming rules

Reuse the durable naming rules from:

• repo-docs/fullstack/suites-and-modules.md
• repo-docs/frontend/modules-and-suites.md

Suite short name rule

A suite short name follows:

{providerId}-{suiteName}

In this repository:

• suiteName must use lowercase English letters only
• suiteName must not contain another -

So a name such as crm-core is not valid as the suiteName segment.

When a proposed name is invalid:

• explain whether the invalid part is providerId, suiteName, or the combined short name
• do not collapse those layers into one vague error
• provide the nearest valid alternatives when possible

For example:

• crm-core is invalid as a suiteName
• crm-core can still be a valid suite short name if it is interpreted as:
  • providerId = crm
  • suiteName = core

Module planning rule

Module names should represent capability ownership inside the suite.

Prefer names that:

• map cleanly to a business capability
• remain natural when they become resource owners, controller names, API paths, or menu/page anchors
• avoid technical placeholder words such as base, core, or common unless the module is truly a shared technical layer

If more detail is needed, prefer expressing it in the module name rather than by making the suite name longer.