---
name: cabloy-module-removal
description: Use this skill whenever the user wants to remove or delete an existing Cabloy module, retire a demo module, or cleanly take a backend, frontend, or fullstack module out of the monorepo. Trigger for requests such as remove module, delete module, retire module, remove demo module, or remove fullstack module, including equivalent requests in other languages. Prefer it when the task is about deletion order, generated-runtime cleanup, and verification rather than scaffolding or contract evolution.
---

# Cabloy Module Removal

Use this skill when the user wants to remove an existing module from the Cabloy monorepo.

Read the public [Module Removal Playbook](../../../repo-docs/ai/playbook-module-removal.md) for the canonical user/agent-facing workflow. This skill is the thinner orchestration layer: it should classify the removal path, choose the right cleanup branch, and point back to the playbook for the shared operational sequence.

## Goals

1. detect whether the active repository is Cabloy Basic or Cabloy Start
2. classify the removal scope as backend-only, frontend-only, or fullstack
3. keep the workflow source-first instead of debugging generated artifacts too early
4. make the stale-generated-runtime recovery branch explicit when needed
5. finish with verification guidance that proves the module is gone from the runtime/code graph

## Step 1: Detect repo and classify the removal branch

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

Then classify the request into one of three branches:

### Branch A: backend-only removal

Use this branch when the user is removing only Vona-side code such as:

- `vona/src/module/<module>`
- backend package references
- backend tests or metadata tied only to Vona

### Branch B: frontend-only removal

Use this branch when the user is removing only Zova-side code such as:

- `zova/src/module/<module>`
- frontend package references
- Zova-only API/model/component assets

### Branch C: fullstack removal

Use this branch when the module exists on both sides or the request affects both Vona and Zova.

This is the default branch for demo modules and shared business threads.

## Step 2: Inventory real source and direct references first

Before proposing or making cleanup steps, inspect the real module surfaces first:

- backend and frontend module roots
- `vona/package.json`
- `zova/package.json`
- generated registries or lockfiles that may need refresh
- tests tied to the module
- optional docs/examples only if the user explicitly wants a public scrub

Start from the shared root scripts first:

- `package.json`
- `npm run vona`
- `npm run zova`

Do not assume a module lives only in one path family until the actual repo layout has been inspected.

## Step 3: Keep the normal execution order source-first

Point the user or the main workflow to this order:

1. remove backend source if in scope
2. remove frontend source if in scope
3. remove direct workspace dependency references
4. run the repo-owned regeneration flow
5. verify no references remain

Important rule:

- do not start by hand-editing generated caches or type surfaces while the real source and dependency references still exist

Use the playbook for the full operational sequence and representative commands.

## Step 4: Use generated-runtime cleanup only as a recovery branch

When a module has already been removed from source and direct dependency references, but stale generated types or runtime entries still remain, treat generated runtime directories as disposable working state rather than source-of-truth files.

Primary recovery targets for this workflow are:

- `vona/.vona`
- `zova/.zova`

These directories are auto-generated by the Vona and Zova CLI flows and may survive when a service or build process does not stop cleanly.

This is a recovery branch, not the default first step.

After cleanup, rerun the normal build/deps/typecheck flow from the playbook.

## Step 5: Finish with branch-aware verification

Use the verification path that matches the branch:

- backend-only → backend deps/typecheck/tests as needed
- frontend-only → relevant Zova build/deps/typecheck path
- fullstack → fullstack regeneration order plus typecheck and targeted tests

Verification should prove:

- no direct workspace dependency entries remain
- no stale generated registrations remain
- no typecheck failures still point at the removed module
- no important runtime or test surfaces still import the removed module

## Step 6: Treat docs cleanup as a separate scope decision

Do not assume module deletion automatically means public docs cleanup.

Ask or confirm whether the task is:

- code/runtime removal only
- code/runtime removal plus docs/examples scrub

If docs cleanup is in scope, update `repo-docs/` separately from the runtime cleanup. Keep maintainer rationale in `repo-docs-internal/`; do not require a particular internal record as part of module removal.

## Response pattern

When using this skill, structure the response around these points when helpful:

1. detected edition
2. detected removal scope
3. real module surfaces involved
4. recommended cleanup/regeneration branch
5. stale-generated-runtime recovery branch if needed
6. verification steps

Keep the response practical. The value of this skill is to choose the right removal branch quickly and keep generated working state in the correct role.