Skill

Generate Makepad DSL Code and Syntax Explanations

Skill for Makepad's live_design! DSL syntax - prototypes, inheritance/override rules, and linking DSL to Rust structs.


77
Spark score
out of 100
Updated last month
Version 13.1.1
Models
claude

Add to Favorites

Why it matters

Leverage the Makepad DSL expertise to generate Rust UI code, explain syntax, and assist with widget declarations and property overrides within the Makepad framework.

Outcomes

What it gets done

01

Generate Makepad DSL code snippets based on provided patterns.

02

Explain Makepad DSL syntax, inheritance, and property overriding rules.

03

Assist with defining prototypes and composing DSL elements.

04

Help link DSL definitions to Rust structs for UI development.

Install

Add it to your toolbox

Run in your project directory:

curl -fsSL https://spark.entire.vc/get/ag-makepad-dsl | bash

Overview

Makepad DSL Skill

A Makepad DSL reference skill covering live_design! object syntax, prototype inheritance/override rules (eager copy, override, extend, nested override), and linking DSL objects to Rust structs. Use for Makepad live_design! syntax, prototype definitions, or inheritance/override questions. Scoped to the DSL layer specifically - not app boilerplate, layout, animation, or shaders.

What it does

Makepad DSL Skill is an expert reference for the live_design! DSL used by the Rust makepad-widgets crate, covering object definitions, inheritance patterns, and property overriding (tracks the makepad-widgets dev branch). It generates DSL code following documented patterns and explains DSL syntax, inheritance, and property-overriding rules rather than generic Rust syntax.

Before answering, it is instructed to read local dsl-syntax.md and inheritance.md reference files and incorporate their content, falling back to SKILL.md patterns plus built-in knowledge if a file is missing or empty (surfacing a documentation-sync command to the user in that case).

PrimaryButton = <MyButton> {
    draw_bg: { color: #0066CC }  // Override parent color
    draw_text: { color: #FFFFFF }  // Add new property
}

Five key patterns are documented with working code: anonymous objects ({ ... } with no name), named objects/prototypes (Name = { ... } for reusable styles), inheritance with override (<Parent> { ... } overriding or adding properties), widget instantiation with nested children (a <View> containing <Button> and <Label> children), and linking a Rust struct to DSL via the {{RustType}} syntax paired with a #[derive(Live, LiveHook, Widget)] struct using #[deref] and #[live] field attributes. A DSL syntax reference table covers six constructs (anonymous object, named prototype, inheritance, Rust-struct link, named child widget, resource dependency via dep("...")), and a property-types table covers seven value kinds (number, color hex, string, enum, size keyword like Fit/Fill, nested object, array).

Four inheritance rules are stated explicitly: eager copy (all parent properties are copied immediately at definition time, not referenced lazily), override (a child can override any parent property), extend (a child can add new properties not in the parent), and nested override (a child can override part of a nested object while leaving the rest of that nested object unchanged) - illustrated with a worked example where overriding only nested: { x: 30 } leaves the parent's y: 20 intact.

Five rules govern code generation: use <Widget> syntax to inherit from built-in widgets, define reusable styles as named prototypes, use {{RustType}} to link DSL to Rust structs, override only the properties that actually need to change, and use meaningful names for child widget references. Four conceptual points guide question-answering: inheritance is "eager copy" (properties copied at definition time, not live-referenced), the DSL is embedded in Rust via the live_design! macro, DSL changes live-reload without recompilation, and named objects (prototypes) are distinct from widget instances.

When to use - and when NOT to

Use this skill when working with Makepad live_design! syntax, object definitions, or inheritance patterns, or when the task involves widget declarations, property overrides, prototypes, or DSL composition rules specifically - not for generic Rust syntax questions.

It is scoped to Makepad's DSL layer specifically, not app boilerplate, layout, animation, or shader authoring covered by sibling Makepad skills. It is not a substitute for environment-specific validation, testing, or expert review - if local reference documentation is missing, it flags this explicitly rather than silently guessing beyond its built-in knowledge.

Inputs and outputs

Inputs: a request to define, extend, or override a Makepad widget prototype, or a question about DSL inheritance/composition behavior.

Outputs: live_design! DSL code (prototypes, inheritance chains, widget instances) and, where relevant, the matching Rust struct definition linked via {{RustType}}.

Integrations

Part of the Makepad skill family alongside basics, layout, animation, event/action, font, shader, deployment, and reference skills; references local dsl-syntax.md and inheritance.md documentation kept in sync via a /sync-crate-skills makepad command.

Who it's for

Makepad developers defining reusable widget styles, building inheritance-based component libraries, or troubleshooting DSL property-override behavior.

FAQ

Common questions

Discussion

Questions & comments · 0

Sign In Sign in to leave a comment.