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.