Create Module Skill

Create a new module by copying and renaming the tasks template module.

Prerequisites

• The canonical template module src/modules/tasks must exist
• You need a name for the new module (kebab-case)

Steps

1. Ask for the module name

Prompt user for the new module name in kebab-case (e.g., my-feature, user-settings)

1b. Crud-only option

On this stack crud-only keeps every file and only thins the store test (the Node stack's option of the same name removes files its template carries and this one does not).

Ask: is this module pure CRUD (list/get/create/update/delete, no business logic beyond the standard pass-through actions)? If yes, scaffold crud-only — same files, but the generated store test uses the thin form (step 6b): one test that exercises each action once, no dedicated happy/error-path block per action (see /feature Phase 1 §5 — pass-through store actions). If the module will carry any custom logic beyond CRUD, scaffold normally and let /feature add tests as that logic lands.

2. Derive naming conventions

Follow /naming for the full reference. Quick summary from the module name (e.g., my-feature):

• kebab-case: my-feature (folder names, file prefixes, routes)
• PascalCase: MyFeature (component names in JS/templates)
• UPPER_SNAKE_CASE: MY_FEATURE (env keys, constants)
• lowerCamelCase: myFeature (variable names, function names, store exports)

3. Duplicate the module

cp -r src/modules/tasks src/modules/{new-module-name}

4. Rename references

Search and replace the following tokens across the new module:

• tasks → {new-module-name} (kebab-case)
• Tasks → {NewModuleName} (PascalCase)
• TASKS → {NEW_MODULE_NAME} (UPPER_SNAKE_CASE)
• task → {new-module} (singular kebab-case, if applicable)
• Task → {NewModule} (singular PascalCase, if applicable)

Files to check:

• Component names and file names
• Route paths and names
• Store/Pinia modules
• API endpoint names
• Type/interface names
• Config keys
• Test file names and test descriptions

5. Apply renames carefully

• Case-sensitive, whole-word matches where possible
• Show plan before applying if many files affected
• Don't rename unrelated code (e.g., "tasks" in comments about other features)

6. Config-driven values

Business values (plans, roles, feature flags) should be driven by module config, not hardcoded in stores or components.

Pattern:

• Define in src/modules/{module}/config/{module}.development.config.js (and env-specific variants)
• Access via the centralized config service (import config from '@/lib/services/config')

6b. Crud-only: trim the store test

If step 1b chose crud-only, replace the copied {module}.store.unit.tests.js with the thin form: one it() per renamed action that calls it once (mocking axios and the config service exactly as the template does) and asserts the resulting state — keep the template's error-path test for any action that changes state after its await, instead of the template's per-action describe blocks with happy- and error-path cases. Check it with /verify's coverage report — the thin form must still clear vitest.config.js's per-file thresholds; if it doesn't for a given action, keep that action's own test.

7. Verify & report

Run /verify, then report: module path, renamed tokens, lint/test results, next steps (customize logic, update routes in src/router).