mx-discover

name

mx-discover

description

Mendix-specialized domain inventory. Use BEFORE designing any Mendix feature, redesigning a microflow, adding entities, or extending an existing app. Auto-invokes the mendix-expert subagent, lists in-scope entities + associations + relevant microflows + available marketplace modules, and produces a DOMAIN_INVENTORY block. Refuses to proceed to design until the inventory is on the table. Born from the Apr-2026 Next_Best_Action rewrite.

mx-discover

Mendix-day-job version of the generic /discover skill. Mendix design rewrites are expensive — domain models trigger migrations, microflows have non-obvious side effects, marketplace modules already solve common needs. Skipping inventory is the leading cause of rework on Neo's Mendix work.

North star

Don't design Mendix features without first inventorying entities, associations, and microflows.

The Next_Best_Action rewrite happened because the design proposed parameter keys that already existed in the domain. Five minutes of inventory would have caught it.

When to invoke

Auto-invoke when the request involves any of:

• Designing a new Mendix feature (entity, page, microflow, workflow).
• Adding a parameter, attribute, or association to an existing entity.
• Designing a Next_Best_Action / suggestion / recommendation feature in particular (the original failure mode).
• Choosing whether to build vs. consume a marketplace module.
• Renaming an entity / attribute / microflow.
• Modifying domain model in ways that may trigger a migration.

Do not invoke for:

• Pure bug fixes inside a single microflow with a clear root cause.
• Read-only questions ("what does this microflow do?").
• CLI-only operations (mx build, mx push).
• Work where a current inventory already exists in this session.

What it does

1. Announce. "Running /mx-discover before designing -- inventorying domain first."
2. Spawn the mendix-expert subagent with a focused brief: "List entities, associations, and microflows in scope for <feature>. Include marketplace modules already installed that may overlap. Highlight any naming collisions with the proposed feature." Use the Agent tool with subagent_type mendix-expert.
3. In parallel, scan the project locally:
   • *.mpr location and last-modified time (is this even a Mendix project?)
   • marketplace.json / dependencies.json for installed modules
   • userlib/ for custom Java actions
   • Any CLAUDE.md / .claude/ notes specific to this Mendix project
4. Produce DOMAIN_INVENTORY -- a single concise block:

   ## DOMAIN_INVENTORY for <feature>
   
   **In-scope entities:**
   - <Entity> -- <key attributes> -- <associations>
   
   **Existing microflows that may overlap:**
   - <Microflow> -- <one-line purpose>
   
   **Marketplace modules already installed:**
   - <Module> -- <what it provides> -- <reuse vs. build>
   
   **Naming collisions to avoid:**
   - <name> -- already exists as <kind>
   
   **Migration risk:**
   - <attribute change that would trigger a migration>
   
   **Gaps / open questions:**
   - <thing the inventory couldn't determine>
   

5. Stop. Wait. Do not propose design or write any Mendix changes until Neo confirms the inventory.
6. Hand off to design phase, referencing inventory items by exact name.

Hard rules

• Always invoke mendix-expert first. It reads ~/.claude/rules/mendix.md, mendix-cli.md, mendix-mcp.md, and the wiki — that context is load-bearing.
• Refuse to skip inventory even if Neo says "just design it." Push back: "Five minutes of inventory now beats the Next_Best_Action rewrite. Let me see entities first."
• Flag domain-model migrations explicitly. Any attribute add / type change / association rewire is a migration risk. Call it out by name in the inventory.
• Prefer marketplace modules to hand-rolled features when the inventory shows an existing module covers ~80% of the need. Don't reinvent Mx Suggestions-style features.
• No design proposals in step 4. Inventory is descriptive only. Design comes after Neo confirms.

Anti-patterns this skill exists to prevent

• Designing the Next_Best_Action feature without inventorying existing entities (the original incident).
• Choosing parameter keys that already exist on a target entity.
• Building a feature that an installed marketplace module already provides.
• Renaming an attribute without checking which microflows reference it (silent breakage).
• Adding an attribute that triggers a destructive migration on dev data.
• Hand-rolling a workflow that the OneSource portal microflows already cover.

Cross-reference

• Generic counterpart: ~/.claude/skills/discover/SKILL.md
• Mendix specialist: ~/.claude/agents/mendix-expert.md
• Mendix doctrine: ~/.claude/rules/mendix.md
• Mendix CLI: ~/.claude/rules/mendix-cli.md
• Mendix MCP: ~/.claude/rules/mendix-mcp.md
• Studio Pro bridge: ~/.claude/skills/mendix-studio-bridge/SKILL.md
• OneSource conventions: ~/.claude/rules/onesource-mcp.md