makepad-2.0-design-judgment

Provides design judgment anchors and routing for Makepad 2.0 GUI development.

747|87|Updated Jan 10, 2026
One-click install
npx skills add https://github.com/ZhangHanDong/makepad-skills --skill makepad-2-0-design-judgment
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: makepad-2.0-design-judgment
Source: https://github.com/ZhangHanDong/makepad-skills/tree/main/skills/makepad-2.0-design-judgment
Command: npx skills add https://github.com/ZhangHanDong/makepad-skills --skill makepad-2-0-design-judgment

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

Makepad 2.0 developers often know the DSL syntax but struggle with architectural decisions: how to structure state, split components, and reason about GPU rendering. This Skill acts as the entry point for any Makepad task, routing syntax questions to the correct specialized skill while applying conceptual design anchors for judgment calls.

Core Features & Use Cases

  • Skill Routing: Maps any Makepad question domain (layout, events, shaders, themes, etc.) to the correct one of 13 compliance-layer skills to co-load.
  • Design Judgment Anchors: Applies six conceptual anchors — Elm Architecture for data flow, Presentational/Container split for components, immediate-mode GPU rendering mental model, Flexbox-style layout, SDF shader thinking, and Flutter-style cross-platform rendering.
  • Anti-Sycophancy Protocol: Anchors answers to Makepad's actual API behavior instead of agreeing with incorrect user approaches.
  • Use Case: When asked "how should I structure a Makepad app with shared state across screens", the Skill routes to app-structure and events skills for syntax, then applies the Elm Architecture anchor to recommend centralized state with Cx::post_action as the async-to-UI bridge.

Quick Start

Ask how to architect or structure a Makepad 2.0 application, such as how to organize state and components for a multi-screen app.

Frequently Asked Questions about makepad-2.0-design-judgment

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I structure state management in a Makepad 2.0 app?

Follow the Elm Architecture pattern: centralize state in the App struct with #[rust] fields, treat handle_actions() as the update function, and use Cx::post_action with SignalToUI as the async-to-UI bridge. Lift shared state to a common ancestor when components need awareness of each other.

How should I split components in Makepad 2.0?

Use the Presentational vs Container distinction. Presentational widgets hold only #[live] fields and delegate rendering via #[deref] view: View, while container widgets hold #[rust] business state and handle child actions. Split any widget doing both rendering and business logic.

Does Makepad 2.0 work like the DOM or React?

No. Makepad redraws a GPU surface every frame rather than maintaining a DOM tree. Think "what do I paint next frame" instead of "modify a node" — redraw(cx) tells the GPU to repaint a region, and there is no virtual diffing or reconciliation.

Does Makepad 2.0 support cascading styles like CSS?

No. Makepad has no cascade or style inheritance; each component's style is self-contained. For consistent visuals across components, define shared tokens in mod.themes and reference theme colors and fonts explicitly from each widget.

When should I load this skill versus other Makepad skills?

Load this skill first for any Makepad task, then co-load at least one compliance skill for syntax. This skill answers "what should I build and how to structure it", while the other 13 skills answer "what does the API do" for layout, widgets, events, shaders, and more.