Describe the UI with familiar web standards
You do not need to enumerate KUI features or APIs. Put the current SDK in the workspace, ask your agent to follow HTML/CSS web standards, and describe layout, style, data and actions. Let it consult the docs, choose native integration and verify the result with MCP.
Project context for an agent
Provide the SDK version, host language, Windows x64 target, build command and a working project. KUI uses HTML/CSS and optional Lua; implementations relying on JavaScript or browser APIs need adaptation.
Target: Forge KUI 3.61.7 / Windows x64 / C++
Start from: examples/workbench
UI: HTML + CSS; data and events: native C++
Task: add an asset filter and an empty-result state.
Acceptance: build succeeds; filtering updates rows; reset restores data.
Inspect: DOM, box model, real input and screenshots.Generate with standard layout
Define inspectable outcomes: navigation width, content layout, window resizing, dataset size, validation and key actions. Supply relevant guides and one complete example so the agent can use real APIs.
Inspect through DevTools and MCP
Enable DevTools in a local debug build and keep the main thread processing events. Connect to the target, read the DOM, box model and styles, exercise real mouse and keyboard input, and save screenshots. Keep authenticated connection URLs inside the debugging process.
Evaluating the first pass
Keep the first submitted code and check build/startup, visual layout and key interactions separately. Record later fixes independently. Standard layout and inspection tools support a more reliable generation workflow. Cross-task success rates require a fixed task set, model and context; this page gives no unmeasured percentage.
Something unclear?
Report an issue on this page →