Teaches coding agents how to build TUIs with TamboUI correctly: API-level selection, render-thread discipline, display-width safety, CSS-aware element authoring, and JFR conventions.
87
90%
Does it follow best practices?
Impact
84%
1.44xAverage score across 5 eval scenarios
Passed
No known issues
Every .focusable() call must be paired with .id("..."). The focus manager refuses to register an element without an id, the .focusable() flag becomes a no-op, and TamboUI logs a continuous stream of WARNING: Focusable element of type X has no ID and will not be registered in the focus chain. Why: focus routing is keyed on stable string ids; without one, the manager has no way to address the element across renders, so it silently drops it from the chain.
.id("chat").focusable() — both modifiers, every time, on every focusable element.id(...), never an inline-generated id (random UUIDs would change every render and defeat the chain)"chat", "trace", "prompt")WARNING: ... line at every register attempt — grep for it before declaring a focus bug a TamboUI buglist, table, textInput) need both this rule and [[persistent-stateful-elements]] — the id matters across renders, and the element instance must survive across renders too.id("chat").focusable() instance every render still registers as a fresh element each frame and resets its scroll/selection state.focusable().focusable() when keyboard or mouse should reach the elementevals
scenario-1
scenario-2
scenario-3
scenario-4
scenario-5
rules
skills