技能介绍

要解决什么问题

很多 CLI/TUI 改动的讨论会停在「体验不好」或「做个更炫的界面」，却没有可执行的交互模型、状态划分和实现边界。结果是 agent 要么写抽象设计评论，要么默认上全屏 TUI，和任务复杂度不匹配。

Terminal UX Orchestrator 面向的是「终端交互质量」本身：把 prompt、确认流、进度与错误态、帮助页与结果页等需求，收敛成另一段编码 agent 能直接实现和验收的工程说明。

技能如何工作

使用前会先对任务做模式分类（审计、设计、实现映射、可行性验证、变更可见性、验证），混合需求时按固定顺序推进：概括目标 → 诊断交互问题 → 推荐交互形态 → 映射到栈 → 必要时查证框架能力 → 展示前后差异 → 给出验证计划。

交互形态按复杂度从低到高优先：命令优先 CLI → 引导式/半交互 CLI → 全量 TUI；不会为「看起来更高级」而强推 TUI。设计阶段会明确主要步骤、关键状态（加载、空结果、错误、取消）、文案与键盘提示策略；实现映射则说明解析、提示、布局、反馈各由哪类库/模块承担，以及状态与导航边界。

技能自带 references/ 下的审计清单、设计原则、交互模式与实现映射等参考，输出默认遵循七段结构：目标摘要、诊断/设计目标、推荐终端设计、实现路径、可行性与证据、可见影响、验证。

适用边界

适合：CLI/TUI 流程重设计、框架选型与「能否支持某交互模式」的查证、改版前后对比说明。
不适合作为主路径：纯 shell 用法讲解、无 UX 问题的参数解析、与终端无关的后端/API 工作、对终端表现无影响的泛泛重构。
混合任务时只处理 UX 切片；语言栈以用户现有约束为准，仅在明显不匹配时才建议换栈。框架能力不确定时会区分「已核实 / 推断 / 待查」，避免把假设写成定论。