ui-theme-qa
Use this skill to find and fix undisciplined Control-node UI in a Godot project — spacing that follows no ladder, font sizes with no modular scale, near-duplicate colours, and text that fails WCAG contrast — by measuring the live editor with the `hera-godot` CLI and snapping theme tokens to a reference corpus. It also reports (without changing) inert container wrappers and decorative nodes. Triggers: "clean up the UI spacing/type/contrast", "the UI values look arbitrary", "tidy the Godot UI", "check UI contrast", or any request to mechanically remove statistical UI-design defects without a redesign. Reductive only; edits per-node theme overrides (undoable), never copy or layout content.
- License 许可
- Apache-2.0
- 最近更新
- 2026-11-14
- Stars
- ★ 1.6k
- Forks
- 491
01 前言 Front Matter
- name
- ui-theme-qa
- description
- Use this skill to find and fix undisciplined Control-node UI in a Godot project — spacing that follows no ladder, font sizes with no modular scale, near-duplicate colours, and text that fails WCAG contrast — by measuring the live editor with the `hera-godot` CLI and snapping theme tokens to a reference corpus. It also reports (without changing) inert container wrappers and decorative nodes. Triggers: "clean up the UI spacing/type/contrast", "the UI values look arbitrary", "tidy the Godot UI", "check UI contrast", or any request to mechanically remove statistical UI-design defects without a redesign. Reductive only; edits per-node theme overrides (undoable), never copy or layout content.
02 资源文件 2
- 参考文档references/reference-corpus.md5.6 KB
- 参考文档references/ui-theme-areas.md14.5 KB
03 SKILL.md 正文
<!-- markdownlint-disable MD013 -->
UI Theme QA (Godot, reductive)
Mechanically remove statistical design defects from a live Godot editor, over
Control nodes. It does not redesign: it snaps theme tokens to a reference
corpus and never touches copy, information order, or layout structure.
Six areas, split by what they may do:
| areas | effect | |
|---|---|---|
| enforcing | spacing · type-scale · color · contrast |
set theme_override_* (undoable) |
| report-only | containers · decoration |
proposals in the report; no mutation |
The report-only pair would have to delete or re-parent nodes, which cannot be
decided mechanically — a node that looks decorative may be a divider, and
flattening a wrapper breaks the $Path/To/Node references scripts rely on. They
measure and surface; a human decides.
Why a pipeline, not one pass: one context holding every rule while fixing a large UI lets loud items crowd out quiet rules, which get silently dropped. So inspection and enforcement are split per area, and findings live in files. The orchestrator (this context) stays thin — it holds routing only; the detailed rules and findings live in the reference doc and the findings files.
Rules SSOT: references/ui-theme-areas.md. Values: references/reference-corpus.md. Read only the area section you are working; do not load all rules into one context.
0. Prep
hera-godot status— confirm one live editor (thelive-editorskill covers setup). If multiple, passhera-godot --instance <pid>to every mutation.hera-godot guidance ui— respect the returned UI mode.- Ensure git is clean or on a branch; each area fix is one commit.
- Enumerate the target Controls:
hera-godot --ids scene tree(edited scene) — this is the static surface the checks read.
1. Inspect (parallel, static, read-only)
Dispatch one inspector per area (spacing, type-scale, color, contrast,
containers, decoration). Each:
- reads only its area section of
references/ui-theme-areas.md, - measures the live editor with the read commands listed there
(
node get --props,eval --lang gdscript get_theme_color,game ui treerects), - writes
findings-<area>.mdusing the schema (each item acheckpredicate, never a status word).
No mutation here. Inspectors snap replacement values to the corpus so the fix is carried in the finding, not invented later.
2. Report
Merge the findings-*.md into one local HTML report and serve it:
python3 -m http.server <port> from the run folder, then hand the user
http://localhost:<port>/. Show measured values verbatim (distinct spacing
values, font-size ratios, contrast ratios). No artifact, no browser auto-open —
link only.
3. Enforce (sequential: spacing → type-scale → color → contrast)
One area enforcer at a time, in order. containers and decoration are skipped
here — they enforce nothing. Each enforcing area:
- loads
findings-<area>.md+ its area section, - re-measures each
checkfrom the live editor; applies the fix only where the predicate is currently false (never trust the finding text), - enforces with
hera-godot node set <path> --prop "<theme_override…>" --value <v>(undoable), snapping to the corpus rung/hex, - commits that area before the next runs.
Order = dependency order: spacing commits before type-scale, color
converges before contrast, and contrast runs last because it depends on the
final colours.
4. Re-inspect (fresh, parallel)
Dispatch fresh inspectors (not the enforcers) to recompute each enforcing
area's check predicates from source and write verify-<area>.md (true =
applied, false = missed). Any false re-enters step 3 for that area only. The
report-only areas have no check — they changed nothing, so there is nothing to
re-verify, and inventing a predicate that always passes would be a lie.
5. Render QA (confirmation only)
hera-godot run --current --wait, then hera-godot screenshot --runtime --analyze for a
before/after and a clipping/blank sanity gate (possible_clipping, nonblank).
hera-godot stop --wait. Render is confirmation, not measurement — the design facts
came from steps 1/3. Update the report in place.
Contract (why this skill exists)
- Thin orchestrator. This context holds routing only. Rules and findings live in files. Holding all areas here reintroduces the capacity drop.
- A check is a predicate, not a status. A finding is a
checkrecomputed from the live editor every time — never a stored "done". Enforcers fix only false predicates; fresh re-inspectors recompute them. - Snap, don't invent. Replacement values come from the corpus, which is rooted in Godot's own default theme plus WCAG. A project's own theme/tokens win over the corpus if present.
- Undoable + reductive. Only per-node theme overrides change, via
node set(Ctrl+Z survives). Copy, order, and layout are inviolable — which is precisely whycontainersanddecorationreport instead of enforce. Widening that would need an explicit opt-in flag, never a quiet default. - Static inspect, render once. Measurement is
node get/eval/game ui tree; the screenshot analyzer is the confirmation gate, not a measurement tool.
Non-interactive
Fast, mechanical, non-interactive. Ambiguous items are proposed in the report, not asked. Redesign-scale decisions (which accent, is this density right) are out of scope — surface them, do not silently pick.
Companion primitives and boundaries
Project-wide Theme construction is available through
resource create Theme <res://theme.tres> plus theme set, and
screenshot diff can locate before/after pixel changes. They complement this
skill but do not change its safe default: enforcement remains undoable per-node
theme overrides, while project-wide resource writes are persistent and not
undoable.
Automatic wholesale restyling remains out of scope. Hera can apply a style an
agent or user has already chosen, but this workflow does not invent taste or
silently replace the project's visual language. See the repo's
docs/UI_THEME_QA_DESIGN.md §11.1.
04 同仓库更多 Skills
migrate-to-e2e
Moves an existing Playwright, Cypress, Selenium, Appium, Detox, Maestro, or TesterArmy suite to e2e one slice at a time, with the old suite running beside the new one until each ported test is proven. Keeps a MIGRATION.md progress file so any later session resumes where the last stopped. Optionally plants a defect to show both suites catch it. Use for /migrate-to-e2e, "migrate our tests to e2e", "port these Maestro flows", "move our TesterArmy tests", or when a project has an e2e config and an older suite still running.
e2e
Writes, runs, and debugs end-to-end tests for web and mobile apps with e2e, the agentic test runner, which mixes agent.act goals with exact locator assertions on a Playwright browser or an iOS or Android device. Also drives a project's running app live over the e2e MCP server to look at a screen, check a UI change, take a screenshot or record a video, and try a locator; and runs bug bashes, parallel e2e explore runs with each bug proven by a repro test. Use when a project depends on e2e or has an e2e.config.ts, when asked for end-to-end, browser, mobile, or agentic UI tests, to check a change in the running app, to QA or bug bash an app or branch, or when an e2e run fails.
create-verification-skill
Generate a project-local verify-<app> skill on top of e2e, so any coding agent can launch the app, check it is worth driving, exercise a feature the way a user does, keep evidence, and bug bash it. Writes the skill, a feature map with one explore charter per feature, and proves it once. Use for /create-verification-skill, "make a verification skill for this repo", or when a project has no scripted way to prove UI behavior.
deja-search
deja-vu memory — search the user's past AI coding sessions with the deja CLI. Holds what they already settled and never wrote into the repo (naming rules, banned or already-tried tools, required checks before merge, preferred values, who owns what). Use before your first edit in a task, before you call a change done or ready to merge, before you recommend a tool, library, design or reviewer, before re-debugging an error that may already be solved, when they say 'didn't we fix this before', 'what did we decide about X' or 'I already have that', and before telling them something on this machine does not exist.
deja-reflect
End-of-session reflection and memory curation with deja-vu. Review what was decided, what commands broke and what repaired them, and record durable project rules or decisions with deja remember so the next session starts with them.
revid
Make, edit, export and post AI videos with Revid (revid.ai) through the Revid MCP server. Use whenever the user wants a short-form or long-form video made (from an idea, a script, a URL, an article, a PDF, a tweet, a product page, their own clips, or a song), wants to find what is going viral on TikTok, YouTube, Instagram or X before making something, wants to edit or re-export an existing Revid project, generate a standalone AI image or clip, make a series episode, or publish and schedule a finished video to connected social accounts. Covers setup (hosted MCP with OAuth, or an API key), the 36 tools, credits, polling and the rules for publishing. Routes to the more specific revid-* skills when one fits.