Conciseness

Mostly efficient — the bulk is dense Windmill-specific knowledge Claude cannot know (non-interactive mode, esbuild classic transform requiring `import React from 'react'`, draft-vs-deployed runnables, lock-file staleness) — but the file inlines two merged H1 guides and repeats guidance: role-passing is explained nearly verbatim twice ('roles records the role the app uses each datatable through; the app's code must pass the same role' and Critical rule 5 'every wmill.datatable call on it passes that role'), and 'always whitelist tables' appears in three places (migration best practices, the migration workflow, and Best Practices #6). Not a 4 because the duplication is beyond minor; not a 2 because the content is largely necessary, not padded filler.

Actionability

Fully executable throughout: a copy-paste `wmill app new --summary "Customer dashboard" --path f/sales/dashboard --framework react19` command, the exact on-disk layout tree, a 17-language extension table, complete runnable code in TypeScript and Python (imports, `main` signature, parameterized queries), and concrete YAML configs. Even failure modes come with exact symptoms ('React is not defined', a blank screen with 'no error thrown').

Workflow Clarity

App creation is sequenced as explicit Step 1–3 with a consent checkpoint for the destructive `--overwrite` flag, and `wmill app lint` is positioned as a validation gate 'after editing, before offering a preview or a deploy', plus a lock-diff review loop after `wmill generate-metadata`. Not a 5 because the creation workflow itself lacks a post-command verification step and the SQL migration workflow relies on an implicit browser modal rather than an explicit validate step.

Progressive Disclosure

No bundle files exist (no references/, scripts/, or assets/), so all ~500 lines live in one SKILL.md — including a second H1 document ('# Windmill Raw Apps', the authoring/platform guide) that the intro claims 'is covered in the companion authoring guide'. The in-file structure (headers, tables) is good, but ~250 lines of authoring-guide and chat-UI content that clearly belongs in a separate reference file are inlined. Fits 'some structure, content that should be separate is inline'; not a 4 because an entire second document inlined in the overview file is more than a minor organization gap.

Specificity

The entire description is 'MUST use when creating raw apps' — it names the domain ('raw apps') but lists zero actions the skill performs (no scaffolding, no CLI commands, no config management). It sits between anchor 1 (pure abstract language) and anchor 2 (domain named, actions minimal/absent), matching 2 because the domain is named while no concrete capability is stated; not 3 because there is no '1-2 concrete actions' content at all.

Completeness

Only the 'when' is present ('when creating raw apps'); the 'what' — that the skill scaffolds apps via `wmill app new`, defines backend runnables, configures datatables and SQL migrations — is entirely absent. This exactly matches anchor 2 ('only when is present without what'); not 3 because anchor 3 requires a clear 'what'.

Trigger Term Quality

'creating raw apps' is the natural phrase a user would say for the primary use case, and 'creating' plus 'raw apps' are relevant keywords — but common variations and synonyms are missing: 'Windmill', 'scaffold', 'app', 'frontend', 'dashboard'. This matches 'some relevant keywords but missing common variations or synonyms'; not 4 because keyword coverage is a single phrase.

Distinctiveness Conflict Risk

'raw apps' is a niche, Windmill-specific term, which limits generic collisions — but the description omits 'Windmill', leaving the term opaque and open to overlap with any other platform's 'raw app' concept or with general app/frontend-creation skills. Somewhat specific but could still overlap with closely related skills; not 4 because the missing platform qualifier and missing capability list give it little to distinguish itself by.