vision 是 super-ux 流水线中位于 ux-foundation 之上的层。foundation 回答谁用产品、为何用；vision 回答产品是什么、拒绝成为什么。没有它，"该不该做这个"就没有能活过最后表态者的答案。它不同于 scenarios.md：scenarios 逐步说明产品做什么，而一个功能可以完全符合场景却违反 anti-vision。
用途与产物：本技能产出两样东西，第二样才是重点——docs/ux/vision.md 文档，以及写入项目自身说明文件的一条愿景对齐规则，让后续每个功能都对照愿景检查，而不是写完就再没人看。链条为 vision → foundation → flows → scenarios → audit，每层向上追溯。链上有口头退出：操作者说 "no scenarios" / «без сценариев» 即可跳过相应层并注明。
使用方式：先读项目本身而非 README，包括 README.md、ARCHITECTURE.md、ROADMAP.md、CHANGELOG.md、docs/ 全部内容，源码入口、主要服务、schema、路由表，营销页面，依赖清单，以及实际 UI；若 docs/ux/foundation.md 已存在必须阅读，愿景不得与其矛盾。随后写清转变：产品出现前用户处于什么混乱，出现后获得什么清晰。再按九层写 docs/ux/vision.md，每层必写，节由编号标识而非英文标题。
九层：1 本质，一句话，不含功能名、UI、技术；2 核心想法，关于世界的一条观察；3 系统做什么，用连续行为动词；4 用户的角色；5 三到五条原则，每条为我做 X 而非 Y；6 反愿景，明确拒绝成为什么，是唯一能终结争论的层；7 视野，两三年方向而非路线图；8 一句话；9 对齐测试，三到五问。
验证与安装规则：检查本质能否经得起换技术重写、各层是否提到功能或厂商、反愿景是否针对真实替代品、原则是否有会被合理选中的反面、是否与 foundation.md 冲突、陌生人能否用对齐测试否掉一个看似合理的功能。然后把规则写入运行主机实际读取的文件：Claude Code 用 CLAUDE.md，Codex 与 opencode 用 AGENTS.md，Gemini 用 GEMINI.md；按 .claude/、.codex/、.gemini/ 标记目录判断主机，显式项目目标优先；多主机项目每个文件都写；规则幂等，已有标题则原地更新。
限制与注意：规则会先对照 anti-vision 与对齐测试检查新功能，对齐则继续并说明服务于愿景哪部分，不对齐则停止并给出冲突层、两条路径并等待决定。bug 修复、重构、依赖、测试、文档等无用户可见面的改动不触发检查。常见错误包括本质写入技术、原则没有反面、缺少反愿景、把视野写成路线图、愿景与 foundation.md 矛盾、把规则装在硬编码路径导致运行代理看不到、只从 README 写愿景。写完文档后运行 python3 docs/ux/lint.py；更多具体步骤与参数暂未提供。