generative-ui
Use when you need to build dynamic, interactive terminal experiences on the fly. Examples: "create a live dashboard in the terminal", "build an interactive file browser", "generate a custom TUI for this workflow".
60
70%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./skills/generative-ui/SKILL.mdQuality
Discovery
89%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This is a solid description with excellent trigger terms and completeness, clearly stating when to use the skill with concrete examples. Its main weakness is that it focuses more on the types of outputs (dashboards, file browsers) rather than the specific actions/capabilities the skill provides (e.g., rendering widgets, handling input, managing layouts). The use of second person ('you need') is noted but the examples are strong enough to compensate.
Suggestions
Add specific concrete actions the skill performs, e.g., 'Generates terminal UI applications with widgets, layouts, keyboard navigation, and real-time data rendering.'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description names the domain (terminal experiences/TUI) and gives examples of specific use cases (live dashboard, interactive file browser, custom TUI), but doesn't list concrete actions the skill performs (e.g., 'renders widgets', 'handles keyboard input', 'creates layouts'). | 2 / 3 |
Completeness | Clearly answers both 'when' ('Use when you need to build dynamic, interactive terminal experiences') and 'what' (build live dashboards, interactive file browsers, custom TUIs). The 'Use when...' clause is explicit with concrete examples. | 3 / 3 |
Trigger Term Quality | Includes strong natural trigger terms users would actually say: 'terminal', 'dashboard', 'interactive', 'TUI', 'file browser', 'live dashboard'. These cover common variations of how users would request this functionality. | 3 / 3 |
Distinctiveness Conflict Risk | The niche of dynamic/interactive terminal UI experiences is quite distinct. Terms like 'TUI', 'live dashboard in the terminal', and 'interactive file browser' are unlikely to conflict with general coding skills or other tools. | 3 / 3 |
Total | 11 / 12 Passed |
Implementation
50%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill provides a well-organized conceptual guide to building dynamic terminal UIs with wsh, featuring useful visual pseudocode patterns and sound design principles. Its main weaknesses are the lack of executable code examples (patterns are illustrative rather than actionable) and moderate verbosity in philosophical/principle sections. The skill would benefit significantly from concrete API call examples and validation steps for the multi-step patterns.
Suggestions
Replace at least 2-3 pseudocode pattern examples with actual executable wsh_* tool calls or curl commands, showing the real API invocations needed to create overlays, panels, and named spans.
Add validation checkpoints to multi-step patterns (e.g., check screen dimensions before layout, verify overlay creation succeeded, handle input capture errors).
Trim the 'Composition Philosophy' and 'Design Principles' sections — much of this (terminal aesthetics, disposability) is contextual wisdom Claude can infer; focus on the non-obvious constraints like terminal size thresholds.
Consider splitting the detailed patterns (Dashboard, Browser, Dialog, Canvas, Wizard, etc.) into a separate PATTERNS.md reference file, keeping SKILL.md as a concise overview with the layer selection guide and 1-2 key examples.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is moderately verbose — the layered capability descriptions and design principles sections contain some unnecessary elaboration (e.g., explaining the philosophy of terminal aesthetics, 'the human chose to work in a terminal'). However, the patterns themselves are fairly lean with useful pseudocode layouts. Some tightening is possible, particularly in the introductory prose and the composition philosophy section. | 2 / 3 |
Actionability | The skill provides visual pseudocode representations of UI layouts rather than executable code or actual API calls. While the patterns are illustrative and give a clear mental model, they are not copy-paste ready — there are no actual wsh commands, tool invocations, or code snippets that Claude could directly execute. The introductory note about wsh_* tools or HTTP fallback adds some guidance but the patterns themselves remain abstract. | 2 / 3 |
Workflow Clarity | The skill presents clear design patterns with logical sequences (e.g., the wizard pattern shows step progression, alt screen mode shows enter/work/exit flow). However, there are no explicit validation checkpoints — no guidance on checking if overlays rendered correctly, handling errors when screen operations fail, or verifying terminal size before proceeding. The 'choose a layer' decision tree is helpful but lacks error recovery paths. | 2 / 3 |
Progressive Disclosure | The content is well-structured with clear headers and logical sections, but it's a monolithic document with no references to external files for detailed API usage, advanced patterns, or examples. The reference to 'wsh:tui' and 'skills/core/' in the preamble provides some cross-referencing, but the main body could benefit from splitting detailed patterns into separate reference files, especially given its length (~250 lines of content). | 2 / 3 |
Total | 8 / 12 Passed |
Validation
100%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
- Repository
- deepgram/wsh
- Commit
4863aaf
- Reviewed
Table of Contents
Is this your skill?
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.