slt

Convert UI requirements into per-frame Context calls for SuperLightTUI terminal UIs.

174|6|Updated Mar 12, 2026
One-click install
npx skills add https://github.com/subinium/SuperLightTUI --skill slt
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: slt
Source: https://github.com/subinium/SuperLightTUI/tree/main/.agents/skills/slt
Command: npx skills add https://github.com/subinium/SuperLightTUI --skill slt

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

SuperLightTUI (SLT) eliminates the repetitive work of building terminal UIs by hand, so you can focus on interactive behavior and layout instead of diffing, focus management, and rendering loops.

Core Features & Use Cases

  • Immediate-mode TUI authoring: Write a single per-frame closure like slt::run(|ui: &mut Context| { ... }) for layout, diffing, and rendering to “just work”.
  • Predictable widget API rules: Consistent builder and Response patterns (including v0.20 changes) to reduce compile-time surprises and speed iteration.
  • State and composition patterns: Manage state in normal Rust variables and use hooks like use_state_named/use_memo/use_effect plus provide/use_context to avoid excessive prop threading.

Quick Start

Tell the assistant: “Use the slt (SuperLightTUI) skill to implement a terminal UI that shows a bordered ‘Hello’ header and a clickable ‘Quit’ button, using v0.20 APIs and returning a Response from the button.”

Frequently Asked Questions about slt

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

FAQPage Schema
How do I build a terminal UI in Rust without manually managing rendering loops and focus?

Immediate-mode Rust TUIs use a single per-frame closure like slt::run(|ui: &mut Context| { ... }) to automatically handle diffing, focus management, and rendering, letting you focus entirely on interactive behavior and layout instead of boilerplate.

How do I manage widget state in an immediate-mode Rust TUI without excessive prop threading?

You manage widget state in normal Rust variables and use hooks like use_state_named, use_memo, and use_effect alongside provide/use_context injection, avoiding the need to thread excessive props through your layout hierarchy.

Does the SuperLightTUI v0.20 API change how widget builders and Response patterns work?

SuperLightTUI v0.20 enforces consistent builder and Response patterns, requiring you to return a Response from widgets like buttons and match verified source signatures to reduce compile-time surprises and avoid removed APIs.

What is the best way to compose interactive layouts in a Rust terminal UI?

The best way to compose interactive layouts is using per-frame Context calls within your closure, leveraging predictable widget state signatures and v0.20 builder rules to construct complex interfaces without manual diffing.

Why does my Rust TUI code fail to compile when using removed widget APIs?

Compile failures happen when using removed APIs; you must debug API mismatches against v0.20 docs and examples, prioritizing verified source signatures before inventing new methods to ensure your widget state signatures match correctly.

Can I use hooks like use_memo and use_effect for state management in a Rust terminal UI?

Yes, you can use hooks like use_state_named, use_memo, and use_effect for state management in Rust terminal UIs, allowing you to store state in normal variables while avoiding excessive prop threading through context injection.