realize-ui

Implements UI blocks as testable presenters with thin views and mandatory render checks.

Updated Jun 12, 2026
One-click install
npx skills add https://github.com/lucolucus/mismagent --skill realize-ui-lucolucus
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: realize-ui
Source: https://github.com/lucolucus/mismagent/tree/main/plugins/mismagent/skills/realize-ui
Command: npx skills add https://github.com/lucolucus/mismagent --skill realize-ui-lucolucus

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Unit tests and successful compilation prove UI logic works, but they cannot prove a screen actually renders correctly — clipped containers, overflowing text, and invisible controls slip through green test suites. This Skill closes that gap when building a UI block in the mismAgent build flow. ## Core Features & Use Cases - Presenter/view split: Separates every UI decision into a plain, unit-testable state-holder/presenter while the view only renders observable state and forwards events. - Mandatory render-check: Requires either an automated smoke/screenshot test from the side's profile gate or a recorded run-the-app check via the run-app-smoke skill, with evidence stored in render-proof/<block-id>/. - Render checklist: Enforces explicit sizing, intentional overflow handling, contrast/visibility, empty/error/loading state rendering, and observable-state recomposition. - Use Case: When the mismAgent worker loads a block with type = ui, this Skill guides TDD on the presenter from tests_nl, then verifies the screen renders correctly before reporting PUBLIC_API and the render-check result back to the worker. ## Quick Start Ask the worker to realize the ui block defined in the building-block manifest, splitting it into a tested presenter and thin view with a recorded render check.

Frequently Asked Questions about realize-ui

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I make UI logic testable without rendering the screen?

Move every decision into a plain presenter or state-holder that holds view state as the framework's native observable state, then unit-test it directly. The view component only renders presenter state and forwards events, containing no logic of its own.

Why do UI bugs slip through when all unit tests pass?

Unit tests and compilation prove logic, not rendering. Clipped containers, overflowing text, and invisible low-contrast controls are invisible to green tests, which is why a separate render-check with real or automated screen rendering is required.

What does the render checklist for a UI block cover?

It covers explicit sizing of windows and containers, intentional overflow handling for long text and lists, contrast and visibility of every control, actual rendering of empty/error/loading states, and recomposition wired through observable state.

What if the project has no automated UI test capability?

Use the run-app-smoke skill to launch the side via its profile run command, walk the render checklist manually, and record the evidence in render-proof/<block-id>/. A recorded real render is the boundary proof; presenter-green alone is never done.

Is manually forcing re-renders an acceptable pattern?

No. A hand-rolled tick or counter-bump to force re-rendering means the state lives in the wrong place. Move it into the presenter as observable state so events re-render through the framework's native mechanism.