{"skill":{"slug":"terminal-ux-orchestrator","displayName":"terminal-ux-orchestrator","summary":"Orchestrate CLI and TUI UX improvement across languages. Use this skill whenever the user wants to audit a terminal interface, redesign a command flow, add o...","description":"---\nname: terminal-ux-orchestrator\ndescription: Orchestrate CLI and TUI UX improvement across languages. Use this skill whenever the user wants to audit a terminal interface, redesign a command flow, add or improve prompts, selectors, forms, tables, progress views, result pages, help screens, keyboard hints, or compare terminal interaction directions. Also use it when the request needs an implementable stack recommendation, visible before/after UX evidence, or current-doc verification for framework feasibility. Do not use it for ordinary shell usage, pure flag wiring, or backend logic that does not materially affect terminal interaction.\n---\n\n# Terminal UX Orchestrator\n\nUse this skill to turn terminal UX requests into implementable engineering work.\nThe goal is not to produce abstract design commentary. The goal is to help an agent diagnose the current interaction, recommend a better terminal flow, map it to a realistic implementation stack, and make the improvement legible to the user.\n\nThis skill is language-agnostic. Keep the solution inside the user's existing stack unless there is a clear mismatch between the desired interaction and the current toolchain.\n\n## Trigger Boundary\n\nUse this skill when the task is primarily about terminal interaction quality, including:\n\n- CLI or TUI flow redesign\n- prompts, confirms, selectors, forms, wizards, step flows\n- help screens, onboarding output, result pages, status summaries\n- progress feedback, empty states, error states, retry or cancel paths\n- keyboard hints, navigation clarity, screen hierarchy, information density\n- choosing a terminal framework or validating whether a framework can support a desired pattern\n- showing what changed in a terminal UX redesign\n\nDo not use this skill as the main path when the task is mainly:\n\n- ordinary shell usage or shell command explanation\n- pure argument parsing or flag plumbing with no meaningful UX question\n- backend logic, storage, networking, or APIs unrelated to terminal interaction\n- generic code cleanup with no user-facing terminal effect\n\nIf the request is mixed, use this skill only for the UX-facing slice and keep the rest scoped to the underlying engineering task.\n\n## Operating Principle\n\nAlways optimize for a design another coding agent can implement and verify.\nPrefer the smallest interaction model that solves the job:\n\n1. command-first CLI\n2. guided or semi-interactive CLI\n3. full TUI\n\nDo not recommend a full TUI just because it looks more sophisticated. Most developer tools benefit more from a clearer guided CLI, better result presentation, and stronger state feedback.\n\n## Request Classification\n\nClassify the task before proposing changes. A single request may combine several modes.\n\n1. **Audit**: review an existing CLI or TUI and identify the highest-impact UX issues.\n2. **Design**: define a new terminal interaction model, states, layout, and copy.\n3. **Implementation mapping**: translate an agreed design into frameworks, modules, and state boundaries.\n4. **Feasibility verification**: check whether a library or framework can actually support the required interaction.\n5. **Change visibility**: make the before/after effect easy to perceive.\n6. **Validation**: define or execute checks that show the redesign works.\n\nIf several modes are present, use this sequence:\n\n1. summarize the goal or current pain\n2. diagnose the interaction problem or define the design target\n3. recommend the interaction model\n4. map it to implementation\n5. verify unstable assumptions when needed\n6. show the visible difference\n7. close with validation\n\n## Workflow\n\n### 1. Choose the interaction shape\n\nPick one primary interaction class:\n\n- **Command-first CLI**: subcommands, flags, static output, low ceremony\n- **Guided CLI**: prompts, confirmations, selectors, short wizards, structured summaries\n- **Full TUI**: persistent state, keyboard navigation, panels, continuous redraw\n\nIf the current design mixes modes poorly, say so and recommend a cleaner primary shape.\n\n### 2. Diagnose the real UX problem\n\nUse `references/audit-checklist.md` to inspect the current or proposed experience.\n\nPrioritize:\n\n- discoverability of primary actions\n- clarity of current state and next step\n- handling of loading, success, empty, error, and cancel states\n- consistency of copy, semantic styling, and keyboard hints\n- terminal-appropriate density and hierarchy\n- match between task complexity and interaction complexity\n\nWhen auditing an existing tool, lead with the 3-7 issues that most affect usability.\n\n### 3. Design the improved flow\n\nUse `references/design-principles.md` and `references/interaction-patterns.md`.\n\nFor every recommendation, define:\n\n- the interaction shape\n- the major steps, screens, or result sections\n- the critical states\n- prompt, hint, error, and success copy strategy\n- entry, retry, back, cancel, and exit behavior\n\nPrefer clarity, momentum, and recovery over decoration.\n\n### 4. Map the design to implementation\n\nUse `references/implementation-mapping.md`.\n\nAlways explain:\n\n- why the chosen stack fits the interaction shape\n- which library or module handles parsing, prompting, layout, styling, and feedback\n- what should become reusable presentation components\n- where state lives and how events or navigation should be handled\n\nIf the user already chose a language, stay inside that constraint unless it is clearly unsuitable.\n\n### 5. Verify feasibility when details may have changed\n\nDo not assume framework capabilities are timeless.\n\nActively verify with official docs or current high-trust sources when:\n\n- the user asks for the latest, current, or best-supported option\n- a design depends on version-sensitive APIs, widgets, or lifecycle behavior\n- you are not sure a library supports a required interaction\n- terminal compatibility, async behavior, mouse support, or resize behavior matter\n- you are comparing several frameworks or libraries\n\nPrefer these sources in order:\n\n1. official documentation\n2. official repositories and examples\n3. release notes or migration guides\n4. high-quality community references\n\nSeparate clearly in the answer:\n\n- stable design guidance\n- verified conclusions\n- assumptions or open risks\n\n### 6. Make the UX delta visible\n\nUse `references/change-visibility.md`.\n\nNever stop at \"this should feel better.\"\nChoose the lightest artifact that makes the improvement obvious:\n\n- concise before/after summary\n- before/after help or result-page structure\n- flow comparison\n- visual mockup when the environment supports it\n- validation-backed summary of the newly clarified states\n\n### 7. Validate the outcome\n\nClose with a small validation plan or the checks you ran.\n\nValidate at least:\n\n- the main happy path\n- one failure or invalid-input path\n- one empty, no-result, or skip path when relevant\n- cancel, quit, or destructive confirmation when relevant\n- narrow terminal or fallback behavior when relevant\n\n## Optional Environment Amplifiers\n\nThis skill should work even in a plain text environment.\nIf extra capabilities are available, use them only when they materially improve the result:\n\n- **Current web or docs access**: verify framework support, version-sensitive APIs, and current best practices\n- **Visual comparison tools**: show competing terminal directions or before/after layouts when text would be ambiguous\n- **Planning or execution helpers**: break a large multi-command redesign into implementation steps\n\nIf these capabilities are unavailable, degrade gracefully:\n\n- provide a text-first comparison\n- state what remains assumed\n- call out any feasibility checks the implementing agent should run next\n\nDo not make this skill depend on another skill being present.\n\n## Output Contract\n\nDefault to this structure unless the user asks for something else:\n\n### 1. Goal or current-state summary\n\nState the target flow or the main UX problem in 2-4 lines.\n\n### 2. Key diagnosis or design goals\n\nList the high-impact problems or the design goals that drive the solution.\n\n### 3. Recommended terminal design\n\nDescribe the interaction model, flow, major states, and presentation choices.\n\n### 4. Implementation path\n\nProvide:\n\n- primary stack recommendation\n- fallback option when relevant\n- module or component breakdown\n- state and event-handling guidance\n\n### 5. Feasibility and evidence\n\nState:\n\n- what is verified\n- what is inferred\n- what still needs checking\n\n### 6. Visible impact\n\nShow how the user should perceive the change.\n\n### 7. Validation\n\nGive a compact verification plan or summarize the checks already run.\n\n## Constraints\n\n- Do not give purely aesthetic advice with no implementation path.\n- Do not over-engineer a full TUI when a guided CLI is enough.\n- Do not overload the terminal with borders, color, or dense tables if simpler output is clearer.\n- Do not hide uncertainty when framework capability is unclear.\n- Do not claim UX improvement without showing what changed.\n- Do not let framework selection override the user's deployment constraints without justification.\n\n## References\n\n- `references/audit-checklist.md`: audit questions for current terminal UX quality\n- `references/design-principles.md`: hierarchy, density, semantics, and feedback guidance\n- `references/interaction-patterns.md`: common terminal interaction patterns and when to use them\n- `references/implementation-mapping.md`: cross-language stack mapping and selection heuristics\n- `references/change-visibility.md`: ways to make the before/after effect obvious\n- `references/tool-coordination.md`: when to use optional verification, visualization, or planning support\n","tags":{"latest":"1.0.0"},"stats":{"comments":0,"downloads":309,"installsAllTime":11,"installsCurrent":0,"stars":1,"versions":1},"createdAt":1778307743392,"updatedAt":1778492885325},"latestVersion":{"version":"1.0.0","createdAt":1778307743392,"changelog":"# Changelog\n\nAll notable changes to `terminal-ux-orchestrator` will be documented in this file.\n\nThe format is based on Keep a Changelog and adapted for skill releases.\n\n## [1.0.0] - 2026-05-09\n\n### Added\n\n- First public release of `terminal-ux-orchestrator`, a language-agnostic skill for improving CLI and TUI user experience.\n- A structured orchestration workflow covering audit, redesign, implementation mapping, feasibility verification, visible before/after comparison, and validation.\n- Clear trigger guidance for terminal UX tasks such as prompts, selectors, forms, wizards, help screens, result pages, status feedback, progress views, and interaction-direction comparison.\n- Cross-language implementation guidance for Go, Python, Node.js/TypeScript, and Rust through bundled reference material.\n- A release-ready evaluation set covering:\n  - auditing an existing Go CLI flow\n  - designing a polished setup experience from scratch\n  - comparing terminal result-page directions\n  - selecting a Python terminal stack with feasibility checks\n  - showing visible UX improvements for stakeholders\n  - verifying non-trigger boundary behavior on non-UX requests\n\n### Changed\n\n- Renamed the skill identity from `terminal-ui-ux` to `terminal-ux-orchestrator` to better reflect its role as an implementation-oriented workflow rather than a style-only design helper.\n- Refined the skill description and default prompt for stronger discoverability and more accurate triggering.\n- Tightened trigger boundaries so the skill focuses on terminal interaction quality and avoids over-triggering on ordinary shell usage, pure flag wiring, or unrelated backend work.\n- Reframed external capabilities such as web verification, visualization, and planning support as optional environment amplifiers instead of hard dependencies.\n- Improved change-visibility guidance so agents are expected to show what changed through before/after structure, flow comparison, or validation-backed summaries rather than vague UX claims.\n\n### Documentation\n\n- Rewrote `SKILL.md` to emphasize practical, implementation-ready output for coding agents.\n- Updated `agents/openai.yaml` with release-facing metadata and a publishable default prompt.\n- Revised bundled references to support optional visualization fallback and lighter coordination rules.\n- Renamed the accompanying design spec to match the published skill identity.\n\n### Validation\n\n- Passed structural validation with the skill validator.\n- Added JSON-valid release eval prompts for publish-time review and smoke testing.","license":"MIT-0"},"metadata":null,"owner":{"handle":"may4748854-rgb","userId":"s178nzmv2e7qek2gsjd5w8ehx186cghv","displayName":"may","image":"https://avatars.githubusercontent.com/u/257442424?v=4"},"moderation":null}