From makepad-skills
Routes Makepad 2.0 GUI questions to specialized skills and applies design anchors for architecture, component splitting, state management, data flow, and rendering.
npx claudepluginhub zhanghandong/makepad-skills --plugin makepad-skillsThis skill uses the workspace's default tool permissions.
> **Role:** Entry-level routing + design judgment anchors for Makepad 2.0 development.
Guides Next.js Cache Components and Partial Prerendering (PPR) with cacheComponents enabled. Implements 'use cache', cacheLife(), cacheTag(), revalidateTag(), static/dynamic optimization, and cache debugging.
Guides building MCP servers enabling LLMs to interact with external services via tools. Covers best practices, TypeScript/Node (MCP SDK), Python (FastMCP).
Generates original PNG/PDF visual art via design philosophy manifestos for posters, graphics, and static designs on user request.
Role: Entry-level routing + design judgment anchors for Makepad 2.0 development. Relationship to other skills: This skill is the liberation layer (释放层). The other 13 Makepad 2.0 skills are the compliance layer (服从层) — they provide DSL syntax, API patterns, widget catalogs. Don't argue with them. Obey them. This skill provides conceptual anchors for design decisions that have no single correct answer.
This skill operates as a quality valve (质量阀门), simultaneously performing two functions:
Key principle: Conceptual anchors set boundary conditions for emergence. They don't instruct the model what to output — they shape the space in which good output emerges. Rules tell you "don't do X". Anchors tell you "think like Y".
For any Makepad question, FIRST identify which compliance skill(s) to co-load:
| Question Domain | Co-load Skill |
|---|---|
App setup, Cargo.toml, hot reload, app_main! | makepad-2.0-app-structure |
DSL syntax, script_mod!, property system | makepad-2.0-dsl |
| Width, height, Flow, Fill, Fit, spacing | makepad-2.0-layout |
| Widget catalog, View, Button, Label, PortalList | makepad-2.0-widgets |
Events, actions, on_click, handle_event | makepad-2.0-events |
| Animator, hover, pressed, state transitions | makepad-2.0-animation |
draw_bg, Sdf2d, pixel fn, GPU shaders | makepad-2.0-shaders |
Splash scripting, script_mod!, hot reload | makepad-2.0-splash |
| Theme colors, fonts, dark/light mode | makepad-2.0-theme |
| Vector graphics, SVG, gradients, tweens | makepad-2.0-vector |
| Performance, GC, draw batching, profiling | makepad-2.0-performance |
| Errors, bugs, widget not showing, FAQ | makepad-2.0-troubleshooting |
| Migrating from 1.x to 2.0 | makepad-2.0-migration |
Always co-load at least one compliance skill. This skill alone is not enough — it provides judgment, not syntax.
When the question involves HOW to organize, structure, or design (not just WHAT syntax to use), apply these conceptual anchors. Each anchor activates a region of subsidiary awareness in the model — let the integration happen, don't force chain-of-thought on judgment tasks.
MatchEvent::handle_actions IS Elm's update function.Cx::post_action + SignalToUI is the canonical async→UI bridge.
Don't invent alternatives.#[live] fields and #[deref] view: View delegation.#[rust] fields that hold business state.#[deref] delegation pattern exists precisely for this.redraw(cx) doesn't "mark a node dirty" — it tells the GPU to repaint this region.Flow.Down = flex-direction: column. Flow.Right = flex-direction: row.align, spacing, padding, margin — semantics match CSS.mod.themes) instead.draw_bg / draw_text are real GPU shaders, not CSS properties.Sdf2d is signed distance fields — describe shapes with math, not bitmaps.border-radius. "How do I animate opacity?" → Answer is a uniform interpolating
between 0.0 and 1.0 in the shader, not a CSS animation.1. READ the user's question
2. ROUTE to compliance skill(s) — confirm DSL syntax and API patterns
3. APPLY judgment anchors — for architecture and design decisions
4. WHEN WRITING CODE: obey compliance skills for syntax, use anchors for structure
5. WHEN ANCHORS CONFLICT WITH API: compliance wins — the API is external reality
The compliance layer is what Polanyi calls "external reality" (外部实在). You serve it, not the user's preferences. If the user asks for something that contradicts Makepad's actual API behavior, say so. Don't be sycophantic.
When answering Makepad design questions:
After generating a response, self-check:
"Could the user have predicted exactly this output from the question alone?"
This skill sits at the top of a 14-skill stack:
┌─────────────────────────────────────────┐
│ makepad-2.0-design-judgment (this) │ ← Liberation layer: WHY & HOW to design
├─────────────────────────────────────────┤
│ makepad-2.0-app-structure │
│ makepad-2.0-dsl │
│ makepad-2.0-layout │
│ makepad-2.0-widgets │
│ makepad-2.0-events │ ← Compliance layer: WHAT syntax to use
│ makepad-2.0-animation │
│ makepad-2.0-shaders │
│ makepad-2.0-splash │
│ makepad-2.0-theme │
│ makepad-2.0-vector │
│ makepad-2.0-performance │
│ makepad-2.0-troubleshooting │
│ makepad-2.0-migration │
└─────────────────────────────────────────┘
When in doubt: compliance skills answer "what does the API do?" This skill answers "what should I build with it?"