docs(skills): add multi-entity naming and config-driven enum rules (#3254)

* docs(skills): add multi-entity naming rule and config-driven enum guidance

* fix(skills): address review feedback on naming and create-module docs

- Use existing organizations module examples instead of hypothetical billing
- Fix file path reference to modules/users/models/users.schema.js
- Renumber orphan 4b as sub-section under step 4

Author: PierreBrisorgueil

.claude/skills/create-module/SKILL.md

@@ -51,7 +51,7 @@ Files to check in `modules/{new-module-name}/`:
 - Policy function names
 - Test descriptions and fixture data
 
-### 4b. Config-driven enums
+#### Config-driven enums
 
 Business values (plans, roles, statuses) must be driven by the module config, never hardcoded in models or schemas.
 
@@ -62,7 +62,7 @@ Pattern:
 
 Example: `config.billing.plans` used in both `billing.subscription.model.mongoose.js` and `billing.subscription.schema.js`.
 
-> Existing reference: `users.schema.js` uses `z.enum(config.whitelists.users.roles)`.
+> Reference: `modules/users/models/users.schema.js` uses `z.enum(config.whitelists.users.roles)`.
 
 ### 5. Apply renames carefully
 

.claude/skills/naming/SKILL.md

@@ -43,6 +43,7 @@ When a module contains multiple entities (e.g., `billing` with `subscription`, `
 | `billing.subscription.model.mongoose.js` | `subscription.model.mongoose.js` |
 | `billing.subscription.schema.js` | `subscription.schema.js` |
 | `organizations.membership.model.mongoose.js` | `membership.model.mongoose.js` |
+| `organizations.crud.service.js` | `crud.service.js` |
 
 Pattern: `{module}.{entity}[.{name}].{type}.js`