终端用户体验编排器

使用此技能将终端用户体验需求转化为可执行的工程任务。

目标不是生成抽象的设计评论，而是帮助代理诊断当前交互问题，推荐更优的终端流程，将其映射到现实可行的实现技术栈，并让改进效果对用户清晰可见。

该技能与编程语言无关。除非现有工具链与期望的交互存在明显不匹配，否则应保持解决方案在用户的现有技术栈内。

触发边界

当任务主要涉及终端交互质量时，请使用此技能，包括：

• CLI 或 TUI 流程重构
• 提示、确认、选择器、表单、向导、步骤式流程
• 帮助页面、引导输出、结果页、状态摘要
• 进度反馈、空状态、错误状态、重试或取消路径
• 键盘提示、导航清晰度、屏幕层级结构、信息密度
• 选择终端框架，或验证某个框架是否支持特定交互模式
• 展示终端用户体验重构中具体的变化内容

不要将此技能作为主要路径用于以下情况：

• 普通 shell 使用或 shell 命令解释
• 仅涉及参数解析或标志处理，无实际用户体验问题
• 与终端交互无关的后端逻辑、存储、网络或 API
• 无用户界面终端影响的通用代码清理

若请求为混合型任务，仅对其中与用户体验相关的部分使用本技能，其余部分仍聚焦于底层工程任务。

操作原则

始终以另一个编码代理能够实现并验证的设计为目标进行优化。

优先采用能完成任务的最小交互模型：

1. 命令优先型 CLI
2. 引导式或半交互式 CLI
3. 完整的 TUI

不要因为某方案看起来更复杂就推荐完整 TUI。大多数开发者工具更受益于更清晰的引导式 CLI、更好的结果展示以及更强的状态反馈。

请求分类

在提出修改建议前，先对任务进行分类。单个请求可能包含多种模式。

1. 审计：审查现有 CLI 或 TUI，识别最高影响力的用户体验问题。
2. 设计：定义新的终端交互模型、状态、布局和文案。
3. 实现映射：将已达成一致的设计转化为框架、模块和状态边界。
4. 可行性验证：检查某个库或框架是否真能支持所需交互。
5. 变更可见性：使前后变化易于感知。
6. 验证：定义或执行检查以证明重构有效。

若多个模式同时存在，按以下顺序处理：

1. 总结目标或当前痛点
2. 诊断交互问题或明确设计目标
3. 推荐合适的交互模型
4. 映射至实现方案
5. 必要时验证不稳定假设
6. 展示可感知的差异
7. 以验证收尾

工作流程

1. 确定交互形态

选择一种主要的交互类型：

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

若当前设计混用多种模式且效果不佳，应指出问题，并推荐更清晰的主形态。

2. 诊断真实的用户体验问题

使用 references/audit-checklist.md 检查现有或拟议体验。

重点关注：

• 主要操作的可发现性
• 当前状态与下一步的清晰度
• 加载、成功、空、错误及取消状态的处理
• 文案、语义样式和键盘提示的一致性
• 适合终端的密度与层级结构
• 任务复杂度与交互复杂度的匹配程度

审计现有工具时，优先列出 3–7 个最影响可用性的核心问题。

3. 设计优化后的流程

参考 references/design-principles.md 和 references/interaction-patterns.md。

每项建议需明确：

• 交互形态
• 主要步骤、界面或结果区块
• 关键状态
• 提示、提示、错误与成功文案策略
• 入口、重试、返回、取消和退出行为

优先考虑清晰性、推进感与恢复能力，而非装饰性。

4. 将设计映射到实现

参考 references/implementation-mapping.md。

必须说明：

• 所选技术栈为何适配该交互形态
• 哪个库或模块负责解析、提示、布局、样式与反馈
• 哪些内容应成为可复用的展示组件
• 状态存放位置，以及事件或导航如何处理

若用户已指定语言，除非明显不适用，否则应在该约束范围内工作。

5. 验证可行性（当细节可能变动时）

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

在以下情况应主动通过官方文档或高可信来源验证：

• 用户要求最新、当前或最佳支持选项
• 设计依赖版本敏感的 API、控件或生命周期行为
• 不确定某库是否支持所需交互
• 终端兼容性、异步行为、鼠标支持或窗口缩放行为重要
• 正在比较多个框架或库

优先使用以下来源（按优先级排序）：

1. 官方文档
2. 官方仓库与示例
3. 发布说明或迁移指南
4. 高质量社区参考资料

在回答中明确区分：

• 稳定的设计指导
• 已验证的结论
• 假设或开放风险

6. 让用户体验差异可见

参考 references/change-visibility.md。

不要止步于“这会感觉更好”。选择最轻量的呈现方式使改进明显：

• 精炼的前后对比摘要
• 前后帮助信息或结果页结构对比
• 流程对比图
• 若环境支持，提供视觉原型
• 基于验证的、新状态清晰化的总结

7. 验证结果

关闭时附上简要的验证计划或已执行的检查项。

至少验证以下内容：

• 主流程（正常情况）是否正常工作
• 一个错误或无效输入的路径
• 一个空结果、无返回或跳过的情况（如适用）
• 取消、退出或破坏性操作确认（如适用）
• 终端尺寸受限或降级行为（如适用）

可选环境增强

此技能应在纯文本环境中正常运行。

若存在额外能力，仅在能显著提升结果时使用：

• 当前网页或文档访问：验证框架支持情况、版本敏感型 API 及最新最佳实践
• 可视化对比工具：当文本描述易产生歧义时，展示不同终端布局或前后对比效果
• 规划或执行辅助工具：将大型多命令重构拆分为可执行的实施步骤

若这些能力不可用，请优雅降级：

• 提供以文本为主的对比方案
• 明确说明仍存在的假设
• 指出后续实现者应自行验证的可行性检查项

不得使本技能依赖其他技能的存在。

输出契约

默认采用以下结构，除非用户另有要求：

1. 目标或当前状态摘要

用 2–4 行概括目标流程或核心用户体验问题。

2. 关键诊断或设计目标

列出对解决方案有重大影响的问题或设计目标。

3. 推荐的终端设计方案

描述交互模型、流程、主要状态及呈现选择。

4. 实施路径

提供：

• 主要技术栈建议
• 如有需要，提供降级选项
• 模块或组件分解
• 状态与事件处理指导

5. 可行性与证据

说明：

• 已验证的内容
• 已推断的内容
• 仍需进一步检查的内容

6. 可见影响

说明用户应如何感知该变更带来的变化。

7. 验证

提供简洁的验证计划，或总结已执行的检查。

约束条件

• 不得仅提供无实现路径的纯美学建议
• 不得过度设计完整 TUI，若引导式 CLI 已足够则无需复杂化
• 若更简单的输出更清晰，不要在终端中堆叠边框、颜色或密集表格
• 当框架能力不明确时，不得隐藏不确定性
• 未展示具体变化前，不得声称用户体验有所改进
• 不得在无合理依据的情况下，让框架选择违背用户的部署约束

参考资料

• references/audit-checklist.md：当前终端用户体验质量的审计问题清单
• references/design-principles.md：层级、密度、语义与反馈的指导原则
• references/interaction-patterns.md：常见终端交互模式及其适用场景
• references/implementation-mapping.md：跨语言技术栈映射与选型启发式方法
• references/change-visibility.md：使前后变化明显可见的方法
• references/tool-coordination.md：何时使用可选的验证、可视化或规划支持