cabloy 5.1.61 → 5.1.63

package/.claude/skills/cabloy-backend-scaffold/SKILL.md

@@ -36,6 +36,8 @@ Then classify the request:
 
 Default to backend-first. Only escalate mentally to a broader fullstack workflow when the backend change obviously crosses the contract boundary.
 
+If the user is still deciding a new business-domain boundary or suite/module naming, use the root `cabloy-domain-planning` skill before scaffolding.
+
 If the task is really a broad cross-stack workflow, consider whether the root `cabloy-workflow` skill is the better primary router.
 
 ## Step 2: Start from Vona CLI and repo entrypoints

package/.claude/skills/cabloy-backend-scaffold/references/follow-up-checklist.md

@@ -15,7 +15,7 @@ After generating or extending a backend thread, check which follow-up layers app
 - OpenAPI metadata
 - inferred DTO opportunities
 - frontend contract impact
-- `@Api.field(...)` ordering when explicit zod schema is present: put `z.xxx(...)` last so later helpers do not get ignored
+- `@Api.field(...)` / `$makeSchema(...)` ordering when an explicit zod/custom schema is present: put that schema last because `makeSchemaLikes(...)` applies arguments right-to-left and later helpers can otherwise be ignored
 
 ## Persistence follow-up
 

package/.claude/skills/cabloy-domain-planning/SKILL.md

@@ -0,0 +1,212 @@
+---
+name: cabloy-domain-planning
+description: Use this skill whenever the user wants to plan a new business domain in this Cabloy repo, such as CRM, OA, training, ERP, or a similar long-lived domain. Trigger when the request is about deciding suite-first structure, proposing or validating providerId, suite, and module names, comparing naming options, confirming names before scaffolding, or keeping a custom naming path open. Prefer it before backend or frontend scaffolding when the main question is domain naming and structure rather than immediate file generation.
+---
+
+# 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:
+
+- `__CABLOY_BASIC__` present → this is Cabloy Basic
+- `__CABLOY_START__` present → this is Cabloy Start
+- neither present → inspect nearby scripts and ask before making edition-specific assumptions
+
+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:
+
+- `cabloy-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:
+
+- `cabloy-docs/fullstack/suites-and-modules.md`
+- `cabloy-docs/frontend/modules-and-suites.md`
+
+### Suite short name rule
+
+A suite short name follows:
+
+```text
+{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.
+
+## Step 6: Propose names in a compact planning table
+
+When the user has not finalized naming, propose:
+
+1. one **recommended** option
+2. one or two **alternatives** if there is a meaningful trade-off
+3. one **custom naming** path
+
+The proposal should be compact and practical. Include:
+
+- `providerId`
+- suite short name
+- Vona suite full name
+- Zova suite full name
+- 3-6 likely first module names
+- which module should be scaffolded first
+
+Use examples such as:
+
+- suite: `demo-training`
+- modules: `training-student`, `training-course`, `training-record`
+
+When helpful, explain why the recommendation is better than obvious alternatives.
+
+## Step 7: Require confirmation before scaffolding
+
+Before suggesting any scaffold execution, explicitly confirm:
+
+- `providerId`
+- suite short name
+- first module names
+- whether the user wants backend-only, frontend-only, or fullstack scaffolding
+
+Do not treat silence as confirmation.
+
+Always leave a custom path available, for example:
+
+- “If you want a different `providerId`, suite short name, or first module set, give the custom names and I will validate them against the repo rules.”
+
+## Step 8: Hand off to CLI-first scaffolding only after confirmation
+
+Once naming is confirmed, route to the real generators rather than hand-authoring structure.
+
+Typical commands are:
+
+```bash
+npm run vona :create:suite <suiteShortName>
+npm run zova :create:suite <suiteShortName>
+npm run vona :create:module <moduleName> -- --suite=<suiteShortName>
+npm run zova :create:module <moduleName> -- --suite=<suiteShortName>
+```
+
+Then route to:
+
+- `cabloy-backend-scaffold` for backend generation and follow-up
+- `cabloy-frontend-scaffold` for frontend generation and follow-up
+- `cabloy-workflow` if the task becomes a broader cross-stack routing problem
+
+## Step 9: Verification
+
+Always finish with a verification path that matches the scope.
+
+Before generation, verify:
+
+- the proposed suite name follows the naming rule
+- the proposed module names are natural business capability owners
+- the command family still exists through `npm run vona` / `npm run zova`
+
+After generation, verify with the narrowest useful checks first:
+
+- `npm run vona :`
+- `npm run zova :`
+- `npm run deps:vona`
+- `npm run deps:zova`
+- `npm run tsc`
+
+For docs or AI-asset changes that accompany this workflow, also verify that referenced public docs and skill descriptions still tell a consistent story.
+
+## Response pattern
+
+When helpful, structure the response around these points:
+
+1. detected edition
+2. suite-first recommendation
+3. recommended naming table
+4. alternatives and trade-offs
+5. custom naming path
+6. confirmation gate before scaffolding
+7. next CLI commands after confirmation
+8. verification steps
+
+Keep the response practical. The value of this skill is to turn vague new-domain requests into a confirmed, valid, and CLI-ready naming plan before any scaffolding starts.

package/.claude/skills/cabloy-frontend-scaffold/SKILL.md

@@ -36,6 +36,8 @@ Then classify the request:
 
 Default to frontend-first. Only escalate mentally to a broader fullstack workflow when the frontend task obviously crosses the contract boundary.
 
+If the user is still deciding a new business-domain boundary or suite/module naming, use the root `cabloy-domain-planning` skill before scaffolding.
+
 If the task is really a broad cross-stack workflow, consider whether the root `cabloy-workflow` skill is the better primary router.
 
 ## Step 2: Start from Zova CLI and repo entrypoints

package/CHANGELOG.md

@@ -1,5 +1,60 @@
 # Changelog
 
+## 5.1.63
+
+### Features
+
+- Add the `basic-app` modal module.
+- Add update functionality.
+
+### Improvements
+
+- Update the force-delete action modal flow.
+- Unify modal command usage.
+- Migrate remaining confirmation dialogs to `basic-app`.
+
+## 5.1.62
+
+### Features
+
+- Add a domain planning skill.
+- Add a masked mobile field to the student resource.
+- Generate an OpenAPI SDK for `demo-student`.
+- Add student summary and force-delete actions.
+- Customize student level renderers.
+- Add the `demo-student` module with a full student CRUD flow.
+
+### Bug Fixes
+
+- Localize the student menu in `zh-cn`.
+- Override the level filter placeholder correctly.
+- Stabilize empty select value mapping.
+- Polish inline select spacing.
+- Forward select blur handling correctly.
+- Refine borderless styling for filter selects.
+- Place explicit schemas last in `demo-student` metadata.
+
+### Improvements
+
+- Clarify level renderer examples.
+- Clarify the standalone tutorial sandbox.
+- Refresh training-student references.
+- Move `demo-student` into the `a-training` suite.
+- Add a suite-first modularization guide.
+- Clarify the thin model facade reading path.
+- Include `demo-student` in the root npm package.
+- Expand source-reading and contract-loop guides.
+- Clean `demo-student` locale resources.
+- Move `TableCell` beans to app scope.
+- Align the student summary query flow.
+- Simplify the student summary action flow.
+- Refine the student level renderer hierarchy.
+- Add a page meta guide and cross-links.
+- Add a rest-resource runtime documentation set.
+- Refine tutorial 4 AI prompt wording.
+- Expand Zova Router ecosystem guides.
+- Add the Zova Table documentation cluster.
+
 ## 5.1.61
 
 ### Features

package/CLAUDE.md

@@ -48,6 +48,7 @@ Before inventing a custom implementation path:
 - After forward regeneration, keep frontend follow-up thin: prefer semantic model facades and reuse the existing resource-owner when the custom API still belongs to the same resource.
 - For the reverse chain, when Vona consumes newly added or changed Zova Admin render/action/metadata, always run `npm run build:zova:admin` before `npm run deps:vona`. Do not treat `build:rest:cabloyBasicAdmin` alone as sufficient, because the Admin JS bundle and rest output must move together.
 - If generated artifacts already contain the expected changes but consumers still behave stale, suspect local dependency drift before making more source edits.
+- For Vona consumption drift after Zova-generated type/rest output changes, if `npm run deps:vona` still leaves stale consumer types, delete `vona/node_modules` and reinstall dependencies before further debugging or hand-patching dependency links.
 - For Cabloy Start, apply the same reverse-chain logic but resolve the Start-specific flavor names and generated-output paths from the active Start repo before recommending commands.
 - Treat legacy docs as input material, not as unquestioned truth. When docs conflict with source code, prefer current source code.
 - For frontend work, assume Cabloy Basic and Cabloy Start share a frontend engineering layer but may diverge in UI layer, frontend flavors, suite/module availability, SSR site baselines, project assets, and generated outputs.

package/cabloy-docs/.vitepress/config.mjs

@@ -38,6 +38,7 @@ const fullstackGroups = [
     items: [
       { text: 'Introduction', link: '/fullstack/introduction' },
       { text: 'Quickstart', link: '/fullstack/quickstart' },
+      { text: 'Suites and Modules', link: '/fullstack/suites-and-modules' },
     ],
   },
   {
@@ -81,6 +82,22 @@ const fullstackGroups = [
       { text: 'Framework Performance', link: '/fullstack/framework-performance' },
       { text: 'Vona + Zova Integration', link: '/fullstack/vona-zova-integration' },
       { text: 'Contract Loop Playbook', link: '/fullstack/contract-loop-playbook' },
+      {
+        text: 'Backend Metadata to Frontend Table Actions',
+        link: '/fullstack/backend-metadata-to-frontend-table-actions',
+      },
+      {
+        text: 'Backend Metadata to Frontend Table Actions Verify Playbook',
+        link: '/fullstack/backend-metadata-to-frontend-table-actions-verify-playbook',
+      },
+      {
+        text: 'Backend Metadata to Frontend Table Actions Debug Checklist',
+        link: '/fullstack/backend-metadata-to-frontend-table-actions-debug-checklist',
+      },
+      {
+        text: 'Backend Metadata to Frontend Table Actions Source Reading Map',
+        link: '/fullstack/backend-metadata-to-frontend-table-actions-source-reading-map',
+      },
       { text: 'Backend OpenAPI to Frontend SDK', link: '/fullstack/openapi-to-sdk' },
       {
         text: 'Frontend Metadata Back to Backend',
@@ -166,6 +183,19 @@ export default defineConfig({
             { text: 'Foundation', link: '/backend/foundation' },
             { text: 'Backend Essentials', link: '/backend/backend-essentials' },
             { text: 'Quickstart', link: '/backend/quickstart' },
+            {
+              text: 'Backend Source Reading Roadmap',
+              link: '/backend/backend-source-reading-roadmap',
+            },
+            { text: 'Vona Source Reading Map', link: '/backend/vona-source-reading-map' },
+            {
+              text: 'Backend Source Reading Verify Playbook',
+              link: '/backend/backend-source-reading-verify-playbook',
+            },
+            {
+              text: 'Backend Source Reading Debug Checklist',
+              link: '/backend/backend-source-reading-debug-checklist',
+            },
           ],
         },
         {
@@ -218,6 +248,10 @@ export default defineConfig({
             { text: 'Model Guide', link: '/backend/model-guide' },
             { text: 'Entity Guide', link: '/backend/entity-guide' },
             { text: 'DTO Guide', link: '/backend/dto-guide' },
+            {
+              text: 'Backend Resource/Module Contract Chain',
+              link: '/backend/backend-resource-module-contract-chain',
+            },
           ],
         },
         {
@@ -263,6 +297,18 @@ export default defineConfig({
           text: 'API & Testing',
           items: [
             { text: 'OpenAPI Guide', link: '/backend/openapi-guide' },
+            {
+              text: 'Backend Contract Emission Specimen',
+              link: '/backend/backend-contract-emission-specimen',
+            },
+            {
+              text: 'Backend Contract Emission Source Reading Map',
+              link: '/backend/backend-contract-emission-source-reading-map',
+            },
+            {
+              text: 'Backend Contract Emission Output Inspection',
+              link: '/backend/backend-contract-emission-output-inspection',
+            },
             { text: 'DTO Infer and Generation', link: '/backend/dto-infer-generation' },
             { text: 'Unit Testing', link: '/backend/unit-testing' },
           ],
@@ -287,6 +333,10 @@ export default defineConfig({
               text: 'Zova Reactivity Under the Hood',
               link: '/frontend/zova-reactivity-under-the-hood',
             },
+            {
+              text: 'Frontend Source Reading Roadmap',
+              link: '/frontend/frontend-source-reading-roadmap',
+            },
             {
               text: 'Zova Source Reading Map',
               link: '/frontend/zova-source-reading-map',
@@ -309,6 +359,8 @@ export default defineConfig({
           items: [
             { text: 'Environment and Config Guide', link: '/frontend/environment-config-guide' },
             { text: 'App Startup Guide', link: '/frontend/app-startup-guide' },
+            { text: 'Zova App Guide', link: '/frontend/zova-app-guide' },
+            { text: 'Root Behaviors Guide', link: '/frontend/root-behaviors-guide' },
             { text: 'System Startup Guide', link: '/frontend/system-startup-guide' },
           ],
         },
@@ -328,9 +380,19 @@ export default defineConfig({
             { text: 'Page Params Guide', link: '/frontend/page-params-guide' },
             { text: 'Zod Guide', link: '/frontend/zod-guide' },
             { text: 'Page Route Guide', link: '/frontend/page-route-guide' },
+            { text: 'A-Router Guide', link: '/frontend/a-router-guide' },
+            { text: 'Zova Router Under the Hood', link: '/frontend/zova-router-under-the-hood' },
+            { text: 'Router View Hosts Guide', link: '/frontend/router-view-hosts-guide' },
             { text: 'Router Tabs Introduction', link: '/frontend/router-tabs-introduction' },
             { text: 'Router Tabs Overview', link: '/frontend/router-tabs-overview' },
             { text: 'Router Tabs Mechanism', link: '/frontend/router-tabs-mechanism' },
+            { text: 'Router Tabs vs Stack', link: '/frontend/router-tabs-vs-stack' },
+            { text: 'Router Stack Guide', link: '/frontend/router-stack-guide' },
+            { text: 'Page Meta Guide', link: '/frontend/page-meta-guide' },
+            {
+              text: 'Router Tabs Layout Integration',
+              link: '/frontend/router-tabs-layout-integration',
+            },
             {
               text: 'Router Tabs Route Meta Cookbook',
               link: '/frontend/router-tabs-route-meta-cookbook',
@@ -356,6 +418,36 @@ export default defineConfig({
               text: 'Zova Form Source Reading Map',
               link: '/frontend/zova-form-source-reading-map',
             },
+            {
+              text: 'Form Scene to Page Meta',
+              link: '/frontend/form-scene-to-page-meta-guide',
+            },
+            {
+              text: 'Permission, formScene, and Action Visibility',
+              link: '/frontend/permission-formscene-action-visibility-guide',
+            },
+            { text: 'Table Guide', link: '/frontend/table-guide' },
+            { text: 'TableCell Authoring Cookbook', link: '/frontend/table-cell-cookbook' },
+            {
+              text: 'Table + Resource CRUD Cookbook',
+              link: '/frontend/table-resource-crud-cookbook',
+            },
+            {
+              text: 'Table Action Visibility & Permission Flow',
+              link: '/frontend/table-action-visibility-permission-flow-guide',
+            },
+            {
+              text: 'Zova Table Under the Hood',
+              link: '/frontend/zova-table-under-the-hood',
+            },
+            {
+              text: 'Zova Table Controller Render Deep Dive',
+              link: '/frontend/zova-table-controller-render-supplement',
+            },
+            {
+              text: 'Zova Table Source Reading Map',
+              link: '/frontend/zova-table-source-reading-map',
+            },
             { text: 'Component Props Guide', link: '/frontend/component-props-guide' },
             { text: 'Component v-model Guide', link: '/frontend/component-v-model-guide' },
             { text: 'Generic Component Guide', link: '/frontend/generic-component-guide' },
@@ -370,20 +462,54 @@ export default defineConfig({
             { text: 'Server Data', link: '/frontend/server-data' },
             { text: 'Fetch Interceptor Guide', link: '/frontend/fetch-interceptor-guide' },
             { text: 'API Guide', link: '/frontend/api-guide' },
+            { text: 'OpenAPI Runtime Under the Hood', link: '/frontend/a-openapi-under-the-hood' },
             { text: 'Model Architecture', link: '/frontend/model-architecture' },
-            { text: 'Model State Guide', link: '/frontend/model-state-guide' },
-            { text: 'Model Resource Owner Pattern', link: '/frontend/model-resource-owner-pattern' },
+            { text: 'Model Runtime Under the Hood', link: '/frontend/a-model-under-the-hood' },
             {
-              text: 'Using ModelResource in Your Module',
-              link: '/frontend/model-resource-usage-guide',
-            },
-            {
-              text: 'Resource Model Best Practices',
-              link: '/frontend/model-resource-best-practices',
-            },
-            {
-              text: 'Resource Model Cookbook',
-              link: '/frontend/model-resource-cookbook',
+              text: 'Resource Models & CRUD',
+              items: [
+                { text: 'Model State Guide', link: '/frontend/model-state-guide' },
+                {
+                  text: 'Model Resource Owner Pattern',
+                  link: '/frontend/model-resource-owner-pattern',
+                },
+                {
+                  text: 'Rest Resource Under the Hood',
+                  link: '/frontend/rest-resource-under-the-hood',
+                },
+                {
+                  text: 'Rest Resource Source Reading Map',
+                  link: '/frontend/rest-resource-source-reading-map',
+                },
+                {
+                  text: 'Resource Entry Page Deep Dive',
+                  link: '/frontend/resource-entry-page-deep-dive',
+                },
+                {
+                  text: 'Resource List Page Deep Dive',
+                  link: '/frontend/resource-list-page-deep-dive',
+                },
+                {
+                  text: 'ModelResource Internals Deep Dive',
+                  link: '/frontend/model-resource-internals-deep-dive',
+                },
+                {
+                  text: 'Filter to Query to Select Data Flow',
+                  link: '/frontend/filter-query-select-data-flow-guide',
+                },
+                {
+                  text: 'Using ModelResource in Your Module',
+                  link: '/frontend/model-resource-usage-guide',
+                },
+                {
+                  text: 'Resource Model Best Practices and Anti-Patterns',
+                  link: '/frontend/model-resource-best-practices',
+                },
+                {
+                  text: 'Resource Model Cookbook',
+                  link: '/frontend/model-resource-cookbook',
+                },
+              ],
             },
           ],
         },
@@ -391,6 +517,26 @@ export default defineConfig({
           text: 'API Contract & SDK',
           items: [
             { text: 'OpenAPI SDK Guide', link: '/frontend/openapi-sdk-guide' },
+            {
+              text: 'Generated Contract Consumption Specimen',
+              link: '/frontend/generated-contract-consumption-specimen',
+            },
+            {
+              text: 'Generated Contract Consumption: List Branch',
+              link: '/frontend/generated-contract-consumption-list-branch',
+            },
+            {
+              text: 'Generated Contract Consumption: Entry Branch',
+              link: '/frontend/generated-contract-consumption-entry-branch',
+            },
+            {
+              text: 'Generated Contract Consumption Verify Playbook',
+              link: '/frontend/generated-contract-consumption-verify-playbook',
+            },
+            {
+              text: 'Generated Contract Consumption Debug Checklist',
+              link: '/frontend/generated-contract-consumption-debug-checklist',
+            },
             { text: 'API Schema Guide', link: '/frontend/api-schema-guide' },
             { text: 'SDK Guide', link: '/frontend/sdk-guide' },
           ],

package/cabloy-docs/ai/docs-skills-rules-mapping.md

@@ -150,6 +150,14 @@ Use this quick rule:
 - avoid putting the full workflow in `CLAUDE.md` because the task needs branching, cleanup order, generated-runtime recovery, and verification
 - procedural decision workflow → `cabloy-module-removal` skill
 
+### Example: “How should AI plan a new business domain name and structure?”
+
+- public naming and suite-first explanation → [Suites and Modules](/fullstack/suites-and-modules)
+- frontend-side naming companion → [Modules and Suites](/frontend/modules-and-suites)
+- keep the durable naming rules in docs instead of duplicating them in repo rules
+- avoid putting the full branching workflow in `CLAUDE.md` because the task needs proposal, validation, confirmation, and CLI handoff
+- procedural decision workflow → `cabloy-domain-planning` skill
+
 ### Example: “What `@Api.field(...)` ordering rule should AI preserve when mixing helpers and zod?”
 
 - full explanation → [Entity Guide](/backend/entity-guide) and [DTO Guide](/backend/dto-guide)

package/cabloy-docs/ai/future-skill-roadmap.md

@@ -13,6 +13,7 @@ A roadmap helps convert that documented knowledge into a focused set of high-val
 Current root skills include:
 
 - `cabloy-workflow`
+- `cabloy-domain-planning`
 - `cabloy-contract-loop`
 - `cabloy-resource-field-update`
 - `cabloy-module-removal`
@@ -20,6 +21,7 @@ Current root skills include:
 Their current roles are:
 
 - `cabloy-workflow` → broad workflow selection, edition detection, CLI-first routing, and verification framing
+- `cabloy-domain-planning` → suite-first naming proposals, providerId confirmation, module-boundary suggestions, and scaffold handoff for new business domains
 - `cabloy-contract-loop` → backend/frontend contract regeneration, reverse-chain handling, and drift diagnosis
 - `cabloy-resource-field-update` → existing backend resource-field changes with `fileVersion` and renderer-aware follow-up
 - `cabloy-module-removal` → backend/frontend/fullstack module deletion order, generated-runtime cleanup, and verification

package/cabloy-docs/ai/skills.md

@@ -41,6 +41,7 @@ For edition-aware skills, use [Edition Detection for AI Workflows](/ai/edition-d
 Current examples include:
 
 - `cabloy-workflow` for choosing the correct Cabloy work path before implementation
+- `cabloy-domain-planning` for proposing and confirming providerId, suite, and initial module names before scaffolding a new business domain
 - `cabloy-contract-loop` for backend/frontend contract regeneration and drift diagnosis
 - `cabloy-resource-field-update` for updating an existing backend resource field thread
 - `cabloy-module-removal` for removing a backend, frontend, or fullstack module cleanly, including generated-runtime cleanup, stale-residue recovery, and verification