终端用户体验协调器（terminal-ux-orchestrator）

终端 UX 编排器 使用此技能将终端 UX 请求转化为可实施的工程工作。目标不是产生抽象的设计评论，而是帮助代理诊断当前交互，推荐更好的终端流程，将其映射到现实的实现栈，并使改进对用户可见。此技能是语言无关的。除非所需的交互与当前工具链明显不匹配，否则应保持解决方案在用户现有的栈内。

触发边界 在以下情况下使用此技能：任务主要涉及终端交互质量，包括：

• CLI 或 TUI 流程重设计
• 提示、确认、选择器、表单、向导、步骤流程
• 帮助屏幕、入门输出、结果页面、状态摘要
• 进度反馈、空状态、错误状态、重试或取消路径
• 键盘提示、导航清晰度、屏幕层次、信息密度
• 选择终端框架或验证框架是否支持所需模式
• 显示终端 UX 重设计的变化

不应将此技能用作主要路径，当任务主要涉及：

• 普通 shell 使用或 shell 命令解释
• 纯粹的参数解析或标志管道，而没有有意义的 UX 问题
• 与终端交互无关的后端逻辑、存储、网络或 API
• 没有用户面向终端效果的通用代码清理

如果请求是混合的，则仅对 UX 面的部分使用此技能，并将其余部分限定在底层工程任务中。

操作原则 始终优化为其他编码代理可以实现和验证的设计。更倾向于解决问题的最小交互模型：

• 命令优先的 CLI
• 引导式 CLI
• 完整的 TUI

不应仅因为它看起来更复杂而推荐完整的 TUI。大多数开发工具更能从更清晰的引导式 CLI、更好的结果呈现和更强的状态反馈中受益。

请求分类 在提出更改之前对任务进行分类。单个请求可能包含多种模式：

• 审计：审查现有的 CLI 或 TUI 并确定最高影响的 UX 问题
• 设计：定义新的终端交互模型、状态、布局和副本
• 实现映射：将同意的设计转换为框架、模块和状态边界
• 可行性验证：检查库或框架是否实际支持所需的交互
• 变化可见性：使更改的效果易于察觉
• 验证：定义或执行检查以显示重设计是否有效

如果存在多种模式，则使用此序列：

• 总结目标或当前痛点
• 诊断交互问题或定义设计目标
• 推荐交互模型
• 将其映射到实现
• 在需要时验证不稳定的假设
• 显示可见的差异
• 以验证结束

工作流程

• 选择交互形状

选择一个主要交互类：

• 命令优先的 CLI：子命令、标志、静态输出、低仪式
• 引导式 CLI：提示、确认、选择器、短向导、结构化摘要
• 完整的 TUI：持续状态、键盘导航、面板、连续重绘

如果当前设计混合模式不良，则指出并推荐更清晰的主要形状。

• 诊断真正的 UX 问题

使用 references/audit-checklist.md 检查当前或拟议的体验。优先考虑：

• 主要操作的可发现性
• 当前状态和下一步的清晰度
• 加载、成功、空、错误和取消状态的处理
• 副本、语义样式和键盘提示的一致性
• 终端适当的密度和层次
• 任务复杂度和交互复杂度之间的匹配

当审计现有工具时，首先提出 3-7 个最影响可用性的问题。

• 设计改进的流程

使用 references/design-principles.md 和 references/interaction-patterns.md。对于每个推荐，定义：

• 交互形状
• 主要步骤、屏幕或结果部分
• 关键状态
• 提示、错误和成功副本策略
• 输入、重试、后退、取消和退出行为

更倾向于清晰度、动力和恢复，而不是装饰。

• 将设计映射到实现

使用 references/implementation-mapping.md。始终解释：

• 为何选择的栈适合交互形状
• 哪个库或模块处理解析、提示、布局、样式和反馈
• 哪些应该成为可重用的呈现组件
• 状态的位置以及事件或导航的处理方式

如果用户已经选择了语言，则在明显不合适的情况下保持在该约束内。

• 在细节可能更改时验证可行性

不要假设框架能力是永恒的。当：

• 用户要求最新、当前或最佳支持的选项
• 设计依赖于版本敏感的 API、部件或生命周期行为
• 不确定库是否支持所需的交互
• 终端兼容性、异步行为、鼠标支持或调整大小行为

时，主动使用官方文档或当前高可信度来源进行验证。