mx-design-review

name

mx-design-review

description

Fresh-context reviewer for a proposed Mendix design. Reads the /mx-discover inventory and the proposed design, then audits independently of the original session for naming collisions, anti-patterns, missing test coverage, security concerns, marketplace-overlap (use vs. build), and migration risk. Read-only against the model. Spawn before committing to any non-trivial Mendix design. Also invocable as /mx-design-review.

mx-design-review

Sycophancy guard for Mendix design work. The author of a design (you, in the parent session) has watched it evolve and is biased toward defending it. This skill spawns a fresh-context reviewer that has none of that history -- only the inventory and the proposal -- and produces an honest verdict.

North star

The design that survives a fresh reviewer is the design worth implementing.

When to invoke

Auto-invoke before any of the following ships:

• A new Mendix feature touching multiple entities or microflows.
• A redesign of an existing feature.
• An entity / attribute / association rename rollout.
• A marketplace-module integration plan.
• A workflow / Next_Best_Action / suggestion-engine design (the original failure-mode class).

Do not invoke for:

• Single-microflow bug fixes with a clear root cause.
• Cosmetic changes (label text, visibility expressions).

What it does

1. Verify inputs.

   • Inventory (DOMAIN_INVENTORY block from /mx-discover) is on the table and <24h old. If missing, refuse and tell the parent session to run /mx-discover first.
   • Proposed design is captured in writing (markdown spec or design doc). Spoken-only proposals don't get reviewed -- write them down first.

2. Spawn the fresh-context reviewer subagent via the Agent tool with subagent_type: fresh-reviewer. Brief:

   • Inventory contents (paste).
   • Proposed design (paste).
   • Review checklist (below).
   • Hard rule: do NOT trust the parent session's framing; treat the design as untested.

3. Reviewer checklist (passed in the brief):

   • Naming collisions: does any proposed name (entity / attribute / association / microflow / page / parameter / variable) already exist in the inventory? Flag every collision with file/path.
   • Domain-model coherence: do new associations make sense? Are cardinalities correct? Are owner-side associations consistent with existing patterns in this app?
   • Marketplace overlap: does an installed marketplace module already provide ≥80% of the proposed feature? Recommend reuse if so.
   • Migration risk: any new attribute / type-change / required flag that triggers a destructive migration? Flag it.
   • Test coverage: are there proposed unit tests for the new microflows? If not, that's a missing-coverage flag.
   • Security: are entity access rules proposed for new entities? Are role assignments explicit? Default-deny vs. default-allow?
   • Performance: any N+1 association walk in proposed microflows? Any missing indexes on entities that get queried?
   • Anti-patterns: silent-fail error handlers, magic strings, hardcoded constants, business logic in pages instead of microflows.
   • Convention adherence: does the design follow the conventions surfaced by /mx-discover's "Existing conventions to follow" section?

4. Return the reviewer's verdict verbatim (do not paraphrase or soften):

## /mx-design-review verdict: [APPROVE | REQUEST CHANGES | ESCALATE]

## Blocking findings
- <category> -- <specific finding> -- <suggested fix>

## Non-blocking observations
- <observation>

## Test coverage gaps
- <microflow> -- <suggested test>

## Sources cited
- /mx-discover inventory (timestamp)
- proposed design (path / paste)
- mendix.md / mendix-cli.md / wiki pages consulted

5. If REQUEST CHANGES, the parent session must address blocking findings before any implementation. Re-run this skill after revisions.

Hard rules

• Refuse to review without an inventory. Inventory is the substrate; review without it is just opinion.
• Refuse to review a verbal-only proposal. Get it in writing first.
• Reviewer subagent is read-only. It cannot modify the project, the inventory, or the proposal.
• Do NOT soften the reviewer's findings when relaying them to Neo. False approves are the failure mode this skill exists to prevent.

Cross-reference

• Inventory: ~/.claude/skills/mx-discover/SKILL.md.
• Reviewer subagent: ~/.claude/agents/fresh-reviewer.md.
• Mendix specialist (consulted by the reviewer): ~/.claude/agents/mendix-expert.md.
• General-purpose review: ~/.claude/skills/fresh-review/SKILL.md.