---
name: erp-kit-update
description: Route requirements changes to the correct erp-kit skill. Use when requirements change midway — adding features, modifying business flows, updating screens, changing module specs, or when unsure which erp-kit skill to re-run after a change.
metadata:
  erp-kit-version: "0.45.0"
---

# Requirements Update Router

Route mid-workflow changes to the correct erp-kit skill. Dynamically discovers available skills — no hardcoded routing tables.

## Version Check

Run `npx erp-kit internal measure versions` from the repo root. If `status` is `"violations"`, relay the findings (each states its own fix) and stop; otherwise proceed.

## Workflow

```
IDENTIFY → DISCOVER → ROUTE → CASCADE → INVOKE
```

## Phase 1: Identify

Ask the user:

1. **What changed?** (free-text description of the change)
2. **Where?** Determine domain from the target:
   - App directory (e.g., `{APP_ROOT}/{APP_NAME}/`) → **App workflow** (skills matching `erp-kit-app-*`)
   - Module directory (e.g., `{MODULE_ROOT}/{MODULE_NAME}/`) → **Module workflow** (skills matching `erp-kit-module-*`)

If the user names a specific app or module, confirm the path. If ambiguous, check both directories.

## Phase 2: Discover

Dynamically discover available erp-kit skills:

1. Glob for `erp-kit-app-*/SKILL.md` or `erp-kit-module-*/SKILL.md` files (based on domain from Phase 1) in the skills directory
2. Read each SKILL.md's frontmatter `name` and `description`
3. Skip `erp-kit-shared` (not directly invocable) and standalone skills with no numeric step (e.g. `erp-kit-app-data`) — only ordered chain skills are routable
4. Sort the remaining skills by their numeric step (extract number from name, e.g. `erp-kit-app-3-plan` → step 3)

This builds the routing table at runtime — new or renamed skills are picked up automatically.

## Phase 3: Route

Match the user's change description against each discovered skill's `description` field. Select the **earliest** skill whose description matches the type of change.

**When ambiguous:** Route to the earliest possible skill in the chain. Earlier skills cascade forward naturally.

## Phase 4: Cascade

After identifying the entry point, warn about downstream skills that need re-running. Use the sorted skill list from Phase 2 — all skills with a higher step number than the routed skill are potential downstream candidates.

Show: "Starting from `<routed-skill>`. After this completes, you'll likely need to re-run: `<downstream-skills>`."

Only list downstream skills that are plausibly affected by the change.

## Phase 5: Invoke

Use the `Skill` tool to invoke the routed skill. Pass the app or module name as the argument.

Example: `Skill: erp-kit-app-3-plan, args: "inventory-management"`

## Multiple Changes

If the user describes multiple changes spanning different skills or domains:

1. Group by domain (app vs module)
2. Within each domain, route to the **earliest** affected skill
3. The cascade will naturally cover later skills
