@tailor-platform/erp-kit 0.4.0 → 0.5.0

package/skills/erp-kit-app-4-plan-review/references/story-resolver-parity.md

@@ -5,6 +5,7 @@
 App: {{APP_NAME}}
 Story docs: {{STORY_DOCS}}
 Resolver docs: {{RESOLVER_DOCS}}
+Module metadata (JSON): {{MODULE_METADATA}}
 
 ## Instructions
 
@@ -20,10 +21,19 @@ From each story doc, extract:
 - Story name (from filename or heading)
 - Resolver section content:
   - `None` → read-only story, skip resolver checks
+  - `N/A` (with optional reason, e.g., `N/A — background job`) → story intentionally has no resolver (skip checks). Common for scheduled jobs, cron tasks, webhook handlers, and system-triggered processes that don't expose a GraphQL endpoint.
   - `- TBD` → story needs resolvers but none documented yet (fail)
   - Resolver links (format: `../../../resolver/<name>.md`) → verify they exist
 - Operations described that imply mutations (create, update, delete, submit, approve, etc.)
 
+## Extraction: Module Metadata
+
+Parse the MODULE_METADATA JSON array. Build a lookup map:
+- Key: module name (e.g., `"business-partner"`)
+- Value: `{ commands: string[], queries: string[] }` from `docs.command` and `docs.query` arrays
+
+This is the authoritative source for which modules, commands, and queries exist.
+
 ## Extraction: Resolver Docs
 
 From each resolver doc, extract:
@@ -44,14 +54,20 @@ For each story:
 | resolver_tbd       | Are there stories still showing `- TBD` for resolvers?                   |
 | link_validity      | Do resolver links in the story resolve to real files?                    |
 | operation_coverage | Do story operations (create/update/delete) have matching resolver types? |
+| module_command_existence | Does the module and command/query referenced in each resolver exist in installed modules? |
 
 ### How to Check
 
 1. Read each story's `## Resolvers` section
 2. If `None` → skip (read-only story)
-3. If `- TBD` → fail: resolver docs not yet created
-4. If links present → verify each link resolves to a file in RESOLVER_DOCS
-5. Cross-check story operations against resolver types (mutation for writes, query for reads)
+3. If `N/A` (with or without reason) → skip (intentionally no resolver, e.g., background job)
+4. If `- TBD` → fail: resolver docs not yet created
+5. If links present → verify each link resolves to a file in RESOLVER_DOCS
+6. Cross-check story operations against resolver types (mutation for writes, query for reads)
+7. For each resolver that references a module and command/query, verify against MODULE_METADATA:
+   - The module name must exist as an entry in the metadata array
+   - The command name must appear in that module's `docs.command` array, or the query name in `docs.query`
+   - If either is missing, report as `module_command_existence` gap
 
 ## Link Format Reference
 
@@ -65,6 +81,8 @@ For each story:
 - **Missing resolver docs**: Story links to a resolver that has no doc
 - **Operation mismatch**: Story describes a create operation but no create resolver exists
 - **Orphaned resolvers**: Resolver doc exists but no story links to it (covered by orphan detection)
+- **Non-existent module**: Resolver references a module that isn't installed (not in MODULE_METADATA)
+- **Non-existent command/query**: Resolver references a command or query that doesn't exist in the referenced module
 
 ## Output Format
 

package/skills/erp-kit-app-5-impl-backend/SKILL.md

@@ -1,11 +1,11 @@
 ---
 name: erp-kit-app-5-impl-backend
-description: Implement backend code for app-compose applications using erp-kit modules. Use after completing plan review with erp-kit-app-4-plan-review. Triggers when implementing backend resolvers, wiring modules, configuring applications, or when the user mentions implementing backend, writing resolvers, or connecting erp-kit modules.
+description: Implement backend code for applications using erp-kit modules. Use after completing plan review with erp-kit-app-4-plan-review. Triggers when implementing backend resolvers, wiring modules, configuring applications, or when the user mentions implementing backend, writing resolvers, or connecting erp-kit modules.
 ---
 
-# App-Compose Backend Implementation
+# Application Backend Implementation
 
-Implement backend resolvers and application configuration for an app-compose application, driven by Tier 1-4 documentation (actors, business flows, stories, screens, resolvers).
+Implement backend resolvers and application configuration for an application, driven by Tier 1-4 documentation (actors, business flows, stories, screens, resolvers).
 
 ## When to Use
 
@@ -44,6 +44,17 @@ Read all resolver and screen specs to build a complete picture:
 
 Classify resolvers per [erp-kit-app-shared/references/resolver-classification.md](../erp-kit-app-shared/references/resolver-classification.md).
 
+> **Parallelize if possible:** Dispatch one agent per resolver spec to extract inputs, outputs, module mapping, and error scenarios. Each agent reads a single resolver doc and returns structured analysis.
+
+### Phase 1b: Scaffolded Code Orientation
+
+`erp-kit app generate code` produces two kinds of files:
+
+- **Reference examples** — `src/resolvers/createUser.ts`, `src/modules.ts`, `src/executors/permissionCreated.ts` show the implementation pattern (command invocation, error handling, context creation). Use these as a guide.
+- **Generated stubs** — Minimal resolver files created from `docs/resolver/*.md`. These are your starting points for actual implementation.
+
+When implementing in Phase 4, follow the patterns from the reference examples. Once all actual resolvers are implemented, delete the reference files that aren't needed by your app.
+
 ### Phase 2: Wire Modules (`src/modules.ts`)
 
 Create the module wiring file that composes all required erp-kit modules.
@@ -67,6 +78,8 @@ Key points:
 - Auth with OAuth2, DPoP, and user profile mapping
 - Generators for Kysely types and seed data
 
+> **Sync barrier:** Module wiring and configuration must complete before resolver implementation. These files are shared across all resolvers.
+
 ### Phase 4: Implement Backend Resolvers and Executors
 
 Write one file per resolver under `src/resolvers/`, one per executor under `executors/`.
@@ -77,6 +90,12 @@ For each resolver, check whether its spec (`docs/resolver/*.md`) documents error
 
 Do not directly mutate module-owned tables via Kysely — always use module commands.
 
+> **Parallelize if possible:** Dispatch one agent per resolver. Each agent writes only to its own files:
+> - `src/resolvers/<resolverName>.ts`
+> - `src/executors/<resolverName>.ts`
+>
+> **Shared-file guard:** `src/modules.ts` and `tailor.config.ts` are written in the sync barrier phase above. Resolver agents must NOT modify these files.
+
 ### Phase 5: Generated Files
 
 - **Kysely types** (`src/generated/kysely-tailordb.ts`) — Auto-generated by `pnpm generate` after deployment. Before deployment, create a minimal placeholder so the codebase typechecks.

package/skills/erp-kit-app-6-impl-frontend/SKILL.md

@@ -1,17 +1,17 @@
 ---
 name: erp-kit-app-6-impl-frontend
-description: Implement frontend code for app-compose applications. Use after deploying the backend with erp-kit-app-5-impl-backend. Triggers when implementing frontend pages, creating React components from screen specs, or when the user mentions implementing frontend, creating pages, or building UI for an app-compose application.
+description: Implement frontend code for applications. Use after deploying the backend with erp-kit-app-5-impl-backend. Triggers when implementing frontend pages, creating React components from screen specs, or when the user mentions implementing frontend, creating pages, or building UI for an application.
 ---
 
-# App-Compose Frontend Implementation
+# Application Frontend Implementation
 
-Implement frontend pages for an app-compose application, driven by screen spec documentation and a deployed backend.
+Implement frontend pages for an application, driven by screen spec documentation and a deployed backend.
 
 ## When to Use
 
 - Implementing frontend pages from screen spec docs
 - Creating React components for ListView, Form, or DetailView screens
-- Building the frontend UI for an app-compose application after backend deployment
+- Building the frontend UI for an application after backend deployment
 
 ## Prerequisites
 
@@ -33,6 +33,8 @@ ANALYZE SCREENS → GENERATE GRAPHQL SCHEMA → IMPLEMENT PAGES → VERIFY
 
 Read all screen specs (`docs/screen/*.md`) to build a complete picture:
 
+> **Parallelize if possible:** Dispatch one agent per screen spec to extract page structure, fields, actions, and navigation. Each agent reads a single screen doc and returns structured analysis.
+
 1. **Screen types** — Identify each screen as ListView, Form (create/edit), or DetailView
 2. **Fields and columns** — Map required columns (ListView), form fields (Form), and detail fields (DetailView) from each spec
 3. **Actions** — Identify navigation actions (create, edit, back-to-list) and mutation actions (save, delete, activate/deactivate)
@@ -41,12 +43,25 @@ Read all screen specs (`docs/screen/*.md`) to build a complete picture:
 
 Run `pnpm generate` in the frontend directory to fetch the GraphQL schema from the deployed backend.
 
+> **Sync barrier:** Schema generation must complete before page implementation. Generated types are shared across all pages.
+
+### Phase 2b: Scaffolded Code Orientation
+
+The scaffolded frontend includes example pages under `src/pages/user-management/` as a reference implementation. Use these to understand the page patterns (ListView, Form, DetailView), component structure, and GraphQL fragment conventions before implementing your actual pages.
+
 ### Phase 3: Implement Frontend Pages
 
+> **Barrier step:** Write shared layout and router files before dispatching page agents. These files are shared across all pages and must not be modified by individual page agents.
+
 Run `pnpm lint`, `pnpm typecheck`, and `pnpm gql-tada:check` regularly during implementation. Fix errors before moving on.
 
 Create pages driven by screen spec docs. Each screen type has a standard implementation pattern.
 
+> **Parallelize if possible:** Dispatch one agent per screen. Each agent writes only to its own directory:
+> - `src/pages/<screen-name>/`
+>
+> **Shared-file guard:** Layout files, router configuration, and generated types are written before dispatch. Page agents must NOT modify shared files.
+
 **Read [pages reference](references/pages.md) for the full pattern catalog.**
 
 Page types and their file structure:

package/skills/erp-kit-app-7-impl-review/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: erp-kit-app-7-impl-review
-description: Review implementation parity between documentation and code for app-compose applications. Use after frontend implementation (step 6) to validate code matches documentation.
+description: Review implementation parity between documentation and code for applications. Use after frontend implementation (step 6) to validate code matches documentation.
 ---
 
 # Implementation Parity Review
@@ -31,26 +31,29 @@ Verify at least `RESOLVER_DOCS` or `SCREEN_DOCS` is non-empty. If no docs exist,
 
 ## Step 2: Dispatch Agents (parallelize if possible)
 
-Launch 4 Agent tool calls in parallel — one per parity check.
+Dispatch agents in parallel — one per item in each group. All groups are dispatched simultaneously.
 Each agent receives: APP_NAME, relevant doc/code file paths.
 Each agent returns: structured JSON per [references/impl-parity-report-format.md](references/impl-parity-report-format.md).
 If a doc or code directory is empty, the agent reports "no files found" and skips.
+All review agents are read-only — no shared-file conflict risk.
 
-| Agent | Prompt Template                                                                  | Inputs                                              |
-| ----- | -------------------------------------------------------------------------------- | --------------------------------------------------- |
-| 1     | [references/resolver-doc-code-parity.md](references/resolver-doc-code-parity.md) | RESOLVER_DOCS, BACKEND_RESOLVERS, BACKEND_EXECUTORS |
-| 2     | [references/screen-doc-code-parity.md](references/screen-doc-code-parity.md)     | SCREEN_DOCS, FRONTEND_PAGES                         |
-| 3     | [references/module-wiring-parity.md](references/module-wiring-parity.md)         | RESOLVER_DOCS, BACKEND_MODULES, BACKEND_CONFIG      |
-| 4     | (build verification — inline, no template)                                       | APP_ROOT                                            |
+| Group | Prompt Template                                                                  | Per-item scope     | Inputs per agent                                             |
+| ----- | -------------------------------------------------------------------------------- | ------------------ | ------------------------------------------------------------ |
+| A     | [references/resolver-doc-code-parity.md](references/resolver-doc-code-parity.md) | One per resolver   | Single RESOLVER_DOC + matching BACKEND_RESOLVER + BACKEND_EXECUTOR |
+| B     | [references/screen-doc-code-parity.md](references/screen-doc-code-parity.md)     | One per screen     | Single SCREEN_DOC + matching FRONTEND_PAGE directory         |
+| C     | [references/module-wiring-parity.md](references/module-wiring-parity.md)         | One per resolver   | Single RESOLVER_DOC + BACKEND_MODULES + BACKEND_CONFIG       |
+| D     | Build verification (inline)                                                      | One global agent   | All source paths                                             |
 
-For agents 1-3:
+With R resolvers and S screens, this produces R + S + R + 1 parallel agents.
+
+For groups A-C:
 
 1. Read the prompt template file
 2. Replace `{{APP_NAME}}` with the resolved app name
-3. Replace doc/code path placeholders with the actual file paths
-4. Dispatch the agent with the filled prompt
+3. Replace doc/code path placeholders with the actual file paths for that single item
+4. Dispatch one agent per item with the filled prompt
 
-For agent 4 (build & sync verification):
+For group D (build & sync verification):
 
 Run build checks and source-doc sync check inline:
 
@@ -60,7 +63,7 @@ cd <APP_ROOT>/frontend && pnpm lint && pnpm typecheck && pnpm build
 erp-kit app sync-check -p <APP_ROOT>/..
 ```
 
-Report pass/fail for each check. `sync-check` detects missing resolver implementations and orphaned docs, so agents 1-3 can skip file-existence checks and focus on content parity.
+Report pass/fail for each check. `sync-check` detects missing resolver implementations and orphaned docs, so groups A-C agents can skip file-existence checks and focus on content parity.
 
 ## Step 3: Aggregate Results
 
@@ -70,8 +73,9 @@ After ALL agents return:
 2. Merge all `gaps[]` arrays into a single list
 3. Merge all `inconsistencies[]` arrays into a single list
 4. Deduplicate: if two gaps share the same `source + target + check`, keep only one
-5. Calculate totals across all summaries
-6. Render the final report below
+5. Deduplicate findings: if agents from groups A and C report the same resolver issue, keep only one
+6. Calculate totals across all summaries
+7. Render the final report below
 
 ## Report Format
 

package/skills/erp-kit-app-shared/references/resolver-classification.md

@@ -21,3 +21,6 @@ Prefer built-in queries over custom resolvers for list/get operations where poss
 | Assign X to Y        | Mutation      | `assign<X>To<Y>`       |
 | Submit/Approve       | Mutation      | `submit<Entity>` etc.  |
 | View/List/Get        | Query         | Built-in (no resolver) |
+| Scheduled/Cron job   | N/A           | No resolver — background worker/job |
+| Webhook handler      | N/A           | No resolver — external trigger |
+| System event         | N/A           | No resolver — internal event processing |

package/skills/erp-kit-module-2-requirements-review/SKILL.md

@@ -52,60 +52,41 @@ After ALL agents return:
 2. Merge all `issues[]` arrays into a single list
 3. Merge all `recommendations[]` arrays into a single list
 4. Calculate totals across all summaries
-5. **Classify severity** — for each non-pass finding, the router assigns a severity based on the finding's `status`, `check`, and `detail`:
-   - `critical`: fundamental design flaw, missing required capability, boundary violation — blocks progress
-   - `major`: significant gap that will likely cause downstream issues — should fix
-   - `nit`: cosmetic, stylistic, or minor improvement — does NOT block the review
-6. **Determine verdict**:
-   - **APPROVED**: zero `critical` and zero `major` findings (nits only, or all pass)
-   - **NEEDS CHANGES**: one or more `critical` or `major` findings
-7. Render the final report below
 
-## Report Format
+## Step 4: Severity Validation
 
-Render the aggregated results as markdown:
+Subagents tend to over-classify. Before rendering the report, re-evaluate every non-pass finding:
 
-### Requirements Review Report
+- **"Is this even this module's responsibility?"** — If the concern belongs to another module or is out of scope, drop it from the report
+- **"Does this block planning?"** → `critical`
+- **"Will this force model/command/query rework?"** → `major`
+- All no → `nit`, regardless of subagent label
 
-**Module:** <MODULE_NAME>
+## Step 5: Determine Verdict
 
----
+- **APPROVED**: zero `critical` and zero `major`
+- **NEEDS CHANGES**: one or more `critical` or `major`
 
-### 1. Best Practices
-
-| Feature | Check | Status | Detail |
-| ------- | ----- | ------ | ------ |
-
-(Populated from agent 1 issues)
-
----
+## Step 6: Render Report
 
-### 2. Module Boundary Consistency
-
-| Feature | Overlapping Module | Overlap Area | Recommendation |
-| ------- | ------------------ | ------------ | -------------- |
-
-(Populated from agent 2 issues where check is `boundary_overlap`)
-
----
+## Report Format
 
-### 3. Dependency Analysis
+Render the aggregated results as markdown:
 
-| Feature | Depends On Module | Dependency Type | Status |
-| ------- | ----------------- | --------------- | ------ |
+### Requirements Review Report
 
-(Populated from agent 2 issues where check is `dependency_analysis`)
+**Module:** <MODULE_NAME>
 
 ---
 
-### 4. Summary
+### 1. Summary
 
 | Aspect               | Status | Details           |
 | -------------------- | ------ | ----------------- |
 | Best Practices       |        | X/Y checks passed |
 | Boundary Consistency |        | X/Y checks passed |
 
-### 5. Recommendations
+### 2. Recommendations
 
 Numbered list of actionable fixes, grouped by severity:
 
@@ -113,7 +94,7 @@ Numbered list of actionable fixes, grouped by severity:
 2. `major` — best practice violations, missing capabilities (should fix)
 3. `nit` — cosmetic, stylistic, minor improvements (informational only)
 
-### 6. Verdict
+### 3. Verdict
 
 **Verdict: APPROVED / NEEDS CHANGES**
 

package/skills/erp-kit-module-3-update-plan/SKILL.md

@@ -0,0 +1,132 @@
+---
+name: erp-kit-module-3-update-plan
+description: Update model/command/query documentation based on plan review (step 4) feedback. Use after erp-kit-module-4-plan-review returns NEEDS CHANGES to apply targeted fixes without re-creating existing docs.
+---
+
+# Fix Plan Documentation from Review Feedback
+
+Apply targeted fixes to model, command, and query documentation based on plan review feedback. Unlike erp-kit-module-3-plan which creates docs from scratch, this skill reads the review report and applies only the necessary changes.
+
+## When to Use
+
+- After erp-kit-module-4-plan-review returns **NEEDS CHANGES**
+- User wants to fix specific gaps or inconsistencies flagged by the review
+- User says "fix the review findings" or "apply the review feedback"
+
+## Step 1: Setup
+
+Define shared context:
+
+- `MODULES_ROOT`: glob `**/modules/*/README.md` and derive the parent directory
+- `MODULE_NAME`: from argument or detect from current working directory
+- `FEATURE_DOCS`: glob `<MODULES_ROOT>/<MODULE_NAME>/docs/features/*.md`
+- `MODEL_DOCS`: glob `<MODULES_ROOT>/<MODULE_NAME>/docs/models/*.md`
+- `COMMAND_DOCS`: glob `<MODULES_ROOT>/<MODULE_NAME>/docs/commands/*.md`
+- `QUERY_DOCS`: glob `<MODULES_ROOT>/<MODULE_NAME>/docs/queries/*.md`
+
+Verify that at least some model/command/query docs exist. If none exist, stop with: "No existing docs found. Use erp-kit-module-3-plan to create docs first."
+
+## Step 2: Extract & Triage Review Findings
+
+Look at the conversation history for the most recent plan review report (from erp-kit-module-4-plan-review). Extract all `critical` and `major` findings.
+
+If no review report is found in conversation history, ask the user: "No review report found in this conversation. Please either run /erp-kit-module-4-plan-review first, or paste the review findings."
+
+### Severity Re-evaluation
+
+The review may over-classify findings. Before accepting each finding, re-evaluate it by reading the relevant feature docs:
+
+- **"Is this a real gap or a design choice?"** — If the feature intentionally omits a command/query/model (e.g., handled by another module, deferred to a later phase, or covered by a generic mechanism), **reject** the finding
+- **"Does the feature doc explicitly require this?"** — Only accept findings for capabilities the feature doc actually specifies. Reject findings that invent requirements the feature does not mention
+- **"Does this block implementation?"** → accept as `critical`
+- **"Will this cause rework during implementation?"** → accept as `major`
+- Neither → downgrade to `nit` (informational only, do not fix)
+
+### Categorize accepted findings into:
+
+1. **Missing docs** — new model/command/query docs that need to be created
+2. **Incomplete docs** — existing docs with missing fields, business rules, or error scenarios
+3. **Inconsistencies** — mismatches between feature docs and model/command/query docs
+
+## Step 3: Plan the Delta
+
+Produce a targeted fix plan listing **only** the changes needed. Format:
+
+### Fix Plan
+
+**Findings rejected** (design choices or not required by feature docs):
+- (list rejected findings with reason — these will NOT be fixed)
+
+**Findings downgraded to nit** (informational, no action):
+- (list downgraded findings with reason)
+
+**Docs to create:**
+- (list new docs with purpose — scaffold these)
+
+**Docs to update:**
+- (list existing docs with specific changes needed — edit in place)
+
+**Docs unchanged:**
+- (explicitly note docs that are fine — do NOT touch these)
+
+## Step 4: Apply Fixes
+
+For each item in the fix plan:
+
+### Missing docs → Scaffold & Populate
+
+Scaffold using `erp-kit` CLI. **Names must be PascalCase** (see [naming convention](references/naming.md)):
+
+```bash
+erp-kit module generate doc model ModelName -p <MODULES_ROOT>/<module-name>
+erp-kit module generate doc command CommandName -p <MODULES_ROOT>/<module-name>
+erp-kit module generate doc query QueryName -p <MODULES_ROOT>/<module-name>
+```
+
+Populate the new docs using the extraction rules from:
+
+- [Model extraction](references/model-extraction.md)
+- [Command extraction](references/command-extraction.md)
+- [Query extraction](references/query-extraction.md)
+
+### Incomplete docs → Edit in place
+
+Read the existing doc, then edit it directly to add the missing content. Do NOT re-scaffold or overwrite.
+
+### Inconsistencies → Align with feature spec
+
+Read both the feature doc and the model/command/query doc, then edit the model/command/query doc to align with the feature spec.
+
+**Important**: Do NOT touch docs listed as "unchanged."
+
+## Step 5: Dispatch Refinement Agents (parallelize)
+
+Launch up to 3 Agent tool calls in parallel — one per doc type that had changes — to review and refine the modified docs. Skip agents for doc types with no changes.
+
+Each agent receives: MODULE_NAME, the list of **changed** doc file paths only, and FEATURE_DOCS for cross-reference.
+
+| Agent | Prompt Template                                                                          | Inputs                                             |
+| ----- | ---------------------------------------------------------------------------------------- | -------------------------------------------------- |
+| 1     | [model-extraction.md](references/model-extraction.md)           | MODULE_NAME, changed model doc paths, FEATURE_DOCS |
+| 2     | [command-extraction.md](references/command-extraction.md)       | MODULE_NAME, changed command doc paths, FEATURE_DOCS |
+| 3     | [query-extraction.md](references/query-extraction.md)           | MODULE_NAME, changed query doc paths, FEATURE_DOCS |
+
+For each agent:
+
+1. Read the prompt template file
+2. Replace `{{MODULE_NAME}}` with the resolved module name
+3. Replace `{{FEATURE_DOCS}}` with the actual file paths
+4. Add to the prompt: "Read the docs at [doc paths]. These were just modified to fix review findings. Cross-reference against the feature docs and the extraction rules. Fix any remaining issues. Edit files directly."
+5. Dispatch the agent with the filled prompt
+
+## Step 6: Validate
+
+Run `pnpm run module:doc:check` and fix any violations.
+
+## References
+
+- [Naming convention](references/naming.md)
+- [Module structure](../erp-kit-module-shared/references/structure.md)
+- [Model extraction rules](references/model-extraction.md)
+- [Command extraction rules](references/command-extraction.md)
+- [Query extraction rules](references/query-extraction.md)

package/skills/erp-kit-module-3-update-plan/references/command-extraction.md

@@ -0,0 +1,87 @@
+# Command Extraction
+
+## Context
+
+Module: {{MODULE_NAME}}
+Feature docs: {{FEATURE_DOCS}}
+
+## Instructions
+
+Read ALL feature docs and extract command (write operation) definitions.
+
+1. Read ALL feature docs at the paths above
+2. For each feature, identify operations that change state
+3. For each operation, extract:
+   - Command name (following naming convention)
+   - Input parameters
+   - Business rules and validations
+   - Error scenarios
+   - Process flow (step-by-step)
+
+## Naming Convention
+
+See [naming.md](naming.md) for the full canonical verb vocabulary.
+
+Key mappings:
+
+| Feature Operation    | Command Name   |
+| -------------------- | -------------- |
+| "Create X" / "Add X" | `createX`      |
+| "Update X"           | `updateX`      |
+| "Delete X"           | `deleteX`      |
+| "Deactivate X"       | `deactivateX`  |
+| "Activate X"         | `activateX`    |
+| "Reactivate X"       | `reactivateX`  |
+| "Set default X"      | `setDefaultX`  |
+| "Assign X to Y"      | `assignXToY`   |
+| "Remove X from Y"    | `removeXFromY` |
+| "Revoke X from Y"    | `revokeXFromY` |
+| "Move X"             | `moveX`        |
+| "Log X"              | `logX`         |
+
+**Banned verbs**: `archive`, `unarchive`, `disable`, `enable`, `add...To...`, `unlink`
+
+## Extraction Rules
+
+### Business Rules
+
+- Extract explicit validation rules from feature scenarios
+- Extract implicit rules from test cases ("should not allow X when Y")
+- Map each rule to an error scenario
+
+### Error Scenarios
+
+- For each business rule violation, define an error code
+- Follow SCREAMING_SNAKE_CASE convention
+- Categories: NOT_FOUND, DUPLICATE, LOCKED/INACTIVE, INVALID_STATE, NO_OP
+
+### Process Flow
+
+- Extract step-by-step flow from feature scenarios
+- Identify branching points (conditional logic)
+- Map to validate → query → mutate pattern
+
+## Output Format
+
+Return your extraction as a structured markdown report:
+
+### Commands
+
+For each command:
+
+#### <commandName>
+
+- **Source features:** list of feature files
+- **Target model:** ModelName
+- **Inputs:**
+
+| Param | Type | Required | Description |
+| ----- | ---- | -------- | ----------- |
+
+- **Business Rules:**
+
+| Rule | Error Code | Error Message |
+| ---- | ---------- | ------------- |
+
+- **Process Flow:** numbered steps
+- **Permissions:** list

package/skills/erp-kit-module-3-update-plan/references/model-extraction.md

@@ -0,0 +1,72 @@
+# Model Extraction
+
+## Context
+
+Module: {{MODULE_NAME}}
+Feature docs: {{FEATURE_DOCS}}
+
+## Instructions
+
+Read ALL feature docs and extract entity/model definitions.
+
+1. Read ALL feature docs at the paths above
+2. For each feature, identify entities that need database models
+3. For each entity, extract:
+   - Fields and their types
+   - Relationships to other entities
+   - State machines (if stateful)
+   - Required constraints (unique, required, etc.)
+4. Resolve cross-feature entity references (same entity mentioned in multiple features)
+
+## Extraction Rules
+
+### Entity Identification
+
+- Look for nouns that represent persistent data
+- Check for explicit "Entity" or "Model" mentions
+- Identify implicit entities from relationship descriptions
+
+### Field Extraction
+
+- Map feature attributes to database field types
+- Identify required vs optional fields
+- Note any validation constraints
+
+### State Machine Extraction
+
+- Look for state diagrams or transition descriptions
+- Extract all possible states
+- Map transitions to operations (verbs → commands)
+
+### Relationship Extraction
+
+- Identify foreign key relationships (N-1, 1-1)
+- Identify junction table needs (N-N)
+- Note cross-module entity references
+
+## Output Format
+
+Return your extraction as a structured markdown report:
+
+### Models
+
+For each model:
+
+#### <ModelName>
+
+- **Source features:** list of feature files
+- **Fields:**
+
+| Field | Type | Required | Description |
+| ----- | ---- | -------- | ----------- |
+
+- **Relationships:**
+
+| Type | Target | Field | Cross-module |
+| ---- | ------ | ----- | ------------ |
+
+- **States:** list of states (if stateful)
+- **State Transitions:**
+
+| From | To  | Trigger (command) |
+| ---- | --- | ----------------- |