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.
94
93%
Does it follow best practices?
Impact
97%
2.77xAverage score across 3 eval scenarios
Passed
No known issues
Process steps in order, do not skip ahead. The end state is an Element class that goes through resolveEffectiveStyle for every sub-component, with a Toolkit factory method, JavaDoc-documented CSS selectors, and tests that assert against BufferAssertions.
tamboui-widgets/src/main/java/dev/tamboui/widgets/{area}/ and read its render method to enumerate every visually distinct piece (e.g., for a Gauge: filled bar, label; for a List: items, scrollbar thumb/track)filled, unfilled, cursor, placeholder, item, header)scripts/list-tamboui-modules.sh to confirm the toolkit module path, then list tamboui-toolkit/src/main/java/dev/tamboui/toolkit/element/ for any existing {Name}Element.java — if one exists, stop and tell the user; the right move is to extend the existing Element, not write a duplicatetamboui-toolkit/src/main/java/dev/tamboui/toolkit/element/<Name>Element.java extending StyledElement (or another existing element base if the widget is stateful)thisrenderContent last — match the existing element filesprivate Style <name>Style; (nullable, no initializer) and private static final Style DEFAULT_<NAME>_STYLE = ...;Style.EMPTY plus a single modifier like .reversed() or .dim() — they compose with whatever the user addsStyle.EMPTY — that breaks CSS resolution; see rules/css-element-style-resolution.mdpublic <Name>Element <name>Style(Style s) { this.<name>Style = s; return this; }renderContent(RenderContext context, Rect area, Buffer buffer), resolve every sub-component style via resolveEffectiveStyle(context, "<name>", <name>Style, DEFAULT_<NAME>_STYLE) (or the pseudo-class overload for selected/focused state)widget.render(area, buffer) — pick whichever is less duplicationRenderThread.checkRenderThread() if the element holds mutable state — StyledElement already does this, but custom render helpers may notdev/tamboui/toolkit/Toolkit.java and add a public static <Name>Element <name>(...) method that constructs and returns the elementgauge, barChart, lineGauge); match the table in the project README<h2>CSS Child Selectors</h2> block listing each <ElementName>-<name> selector and its defaultAGENTS.md with one new rowdocs/src/docs/asciidoc/widgets.adoc if the widget itself is new; if the widget already exists, mention only the new Element wrappertamboui-toolkit/src/test/java/dev/tamboui/toolkit/element/<Name>ElementTest.java using JUnit 5Rect, assert the buffer contents with BufferAssertions, then assert that an explicit style overrides the default and (if you have a TCSS test fixture) that a CSS rule overrides the default but is overridden by an explicit settertesting-standards.md from the user's coding-policy tile./gradlew -q :tamboui-toolkit:test and then ./gradlew -q javadoc — both must pass./gradlew -q assemble to confirm Java 8 source compatibilityscripts/check-display-width.sh (it emits JSON candidates) and triage any new entries against rules/char-width-for-display.md — false positives are expected, but a real violation in your render path means a glyph-width bug