makepad-skills: Claude Code skills for building Makepad 2.0 apps

What makepad-skills solves, and for whom

Makepad 2.0 is a Rust UI framework with its own DSL, its own layout vocabulary (Flow, Fill, Fit, Inset) and its own shader system built around Sdf2d and DrawQuad. An assistant asked to write Makepad code without that context will produce something that looks like Rust and compiles like nothing. This repository is a collection of 14 skill files that supply that context to Claude Code, so the model works from the framework's actual syntax instead of guessing at it.

The intended user is narrow. You need Claude Code installed, you need to be building a Makepad 2.0 application, and you need the skills discoverable from your Claude Code configuration. The README names makepad-2.0-design-judgment as the entry point: it holds what the project calls design judgment anchors (Elm Architecture, Presentational/Container separation, a GPU rendering mental model) and is meant to be loaded first, with the specific skills co-loaded after it. That ordering is a deliberate editorial choice, not a technical requirement, and it tells you the author expects the model to reason about structure before it writes DSL.

If you are evaluating Makepad itself, this repository will not help you decide. It contains no benchmarks, no example applications and no comparison against other Rust UI toolkits. It is documentation shaped for a model's context window.

How the 14 skills are organised and loaded

The repository is a skills directory plus Claude Code plugin metadata. The top level holds .claude-plugin/, CLAUDE.md, README.md, metadata.json and skills/. Each skill under skills/ covers one slice of the framework: app structure and app_main!, the DSL and script_mod!, layout, the widget catalog (View, Button, Label, TextInput, PortalList, Dock), events and on_click, the Animator, shaders, the Splash scripting language, themes, vector graphics, performance, troubleshooting, and migration from 1.x.

The split matters because loading all 14 at once wastes context. The design-judgment skill is the anchor; the rest are referenced as needed. The README describes the relationship in one line: load the entry point first, then co-load specific skills. There is no router, no index file that the README documents, and no dependency resolution between skills. Discovery is the model's job, guided by the descriptions in the table.

The legacy arrangement is a branch rather than a directory. Makepad 1.x skills, including Robius and MolyKit patterns, live on the v1/makepad-1.0 branch. If you are maintaining a 1.x application, you check out that branch instead of main; the two sets are not merged, and the README does not describe a combined mode.

Installing makepad-skills into Claude Code

The README gives three installation routes. The first adds the repository as an additional working directory, which keeps the skills in place and points Claude Code at them. The README shows this as a .claude/settings.json entry:

{
  "additionalWorkingDirectories": [
    "/path/to/makepad-skills"
  ]
}

Replace /path/to/makepad-skills with the directory where you cloned the repository. After restarting Claude Code, the skills directory should be visible to the session. The README does not state whether a reload is required, so treat that as unverified.

The second route symlinks each skill into the user-level skills directory, which keeps one copy on disk and lets you pull updates with git:

for skill in skills/*; do
    ln -sf "$(pwd)/$skill" ~/.claude/skills/
done

Run this from the repository root. Each entry under skills/ becomes a symlink in ~/.claude/skills/; if that directory does not exist, create it first, since the README does not include a mkdir step.

The third route copies the files outright:

cp -r skills/* ~/.claude/skills/

Copying is the simplest and the worst for maintenance: updates to the repository will not reach the copied files until you copy again. For a first real use, install by symlink, then start a Claude Code session in a Makepad 2.0 project and ask it to scaffold a window with a button, so you can see whether the DSL skill is being picked up. If the model falls back to generic Rust UI code, the skills are not being discovered.

Where the skill set runs out

The repository is documentation for a model, and it inherits every weakness of that format. Nothing here is executed. A skill file can describe the shape of app_main! or the Animator's Forward, Snap and Loop states, but it cannot tell you whether the code the model writes actually compiles against the Makepad version you have checked out. The README does not pin a Makepad commit, tag or version, so the skills and the framework can drift apart without any signal in this repository.

The migration skill is the sharpest case. A 1.x to 2.0 migration guide is only as good as the API surface it covers, and the README lists it as one skill among fourteen with no statement about completeness. If you are porting a real application, treat that skill as a starting point and verify each mapping against the Makepad source.

The repository also carries no licence file at the top level, though the README states MIT. The top-level entries are .claude-plugin/, .gitignore, CLAUDE.md, README.md, metadata.json and skills/, with no LICENSE file among them. That is a packaging gap rather than a legal position, but it is the kind of thing that blocks adoption inside an organisation with automated licence checks.

Finally, the last push was on 2026-04-07. That is five months before today, so the project is not being actively developed on the evidence available; do not expect fixes to land quickly if a skill describes an API that has since changed.

makepad-skills against writing your own CLAUDE.md

The obvious alternative is a single CLAUDE.md in your Makepad project, written by hand. It is the same mechanism with a different granularity: one file, always loaded, no discovery step. For a small application, that is cheaper. You write the twenty lines about app_main! and the layout keywords that your project actually uses, and you stop there.

The difference shows up as the framework surface grows. Fourteen skills let you load the shader material only when you are writing shaders, and the animation material only when you are writing an Animator, which keeps the context window focused. A single CLAUDE.md is all-or-nothing: either it covers the whole framework and is loaded on every prompt, or it covers part of it and the model guesses at the rest. Whether that trade is worth it depends on how much of Makepad your project touches. A settings dialog does not need the shader skill; a custom-drawn widget does.

The other alternative is the framework's own documentation. Makepad's repository and its examples are the ground truth, and they are versioned with the code. The skills are a convenience layer over that documentation, and when the two disagree, the code wins.

Editorial conclusion

Adopt it if you already build with Makepad 2.0 inside Claude Code and want the DSL, layout and shader conventions loaded as skills rather than re-explained in every prompt. Skip it if you do not use Claude Code, or if your UI stack is not Makepad: nothing here applies to egui, Iced or Tauri. Before relying on it, open skills/makepad-2.0-migration and check whether its 1.x to 2.0 mappings cover the APIs your codebase actually uses, because that is the skill most likely to be stale and the one whose errors cost the most time.

Frequently asked questions

Official sources

1. Issues
2. README
3. ZhangHanDong/makepad-skills on GitHub