核心定位
把你的产品开发经验，变成 Agent 可执行的 Markdown 标准。
这些标准会放进项目目录里，成为跨 session、跨工具、跨 Agent 都能读取的共同上下文。
它是什么
一套让 Agent 开工前先对齐产品、工程和协作方式的标准。
Motux Build 不是一个具体业务模板，也不是某个框架脚手架。它更像一份给 Codex、Claude、Cursor、CodeBuddy 和其它 Agent 读取的项目工作协议，让它们知道什么时候该问、怎么问、什么时候该做、怎么记录、怎么验证。
给人看
让用户知道开发前要想清楚什么，哪些决策需要自己拍板，哪些技术细节可以交给 AI。
给 Agent 执行
让 Agent 按任务类型读取相关标准，避免每次都从零解释同一套偏好和踩坑经验。
解决哪些问题
它解决的是 AI 开发里最消耗时间的重复纠错。
很多项目不是做不出来，而是每次都在同样的地方返工：需求没问清、界面不自然、上下文丢失、 多个 Agent 互相覆盖、测试和提交不稳定。
需求还没想透就开始写代码
要求 Agent 先追问产品目标、核心假设、用户故事和最小验证路径。
Agent 只会反问，用户还是不知道怎么选
要求 Agent 先给判断、选项和推荐理由，让用户直接选择或补充自己的想法。
界面看起来能用，但不够像人用的产品
把 storyboard、视觉确认、分步交互、按钮反馈和移动端检查前置。
同一个项目里 Codex 和 Claude 信息不同步
把关键进展、决定、风险和下一步写入项目记忆，而不是只留在聊天记录里。
每次开新项目都要重新解释偏好
把你的工作方式、质量标准和安全边界沉淀成可复制文件。
标准更新后，旧项目不敢直接覆盖
先查看版本差异和影响范围，再只更新 Motux 管理的内容，保留项目自己的规则。
运行中项目接入 AI 时容易误改
先读取现有规则，遇到冲突不覆盖，接入阶段只梳理、不乱动业务代码。
开发过程不可回溯
要求小步验证、更新交接、必要时提交 Git，让每次修改都有上下文。
小改动也要重复走完整发布流程
根据实际改动自动选择发布强度，静态站不再套用 Docker 流程。
适合什么用户
尤其适合用 AI 做产品开发，但不想反复教同一件事的人。
产品出身的独立开发者
你擅长判断用户、场景和价值，但不想在工程细节上被反复拖住。
同时使用多个编程 Agent 的用户
你需要不同 Agent 共享项目记忆，避免每换一个工具就丢掉上下文。
经常从 0 做原型的人
你需要新项目快速进入需求澄清、界面确认和最小可验证版本。
想把 AI 接入旧项目的人
你需要先保护已有代码和规则，再逐步把更好的协作标准合并进去。
为什么使用
让用户做自己最强的事，让 AI 补用户最弱的地方。
它的价值不是让流程变重，而是减少反复纠错。用户把产品判断、审美偏好和业务目标讲清楚， AI 则负责把这些判断转化成工程执行、验证和记录。
先把产品想清楚
Agent 先给判断和可选方向，再帮助用户明确为什么要做、谁会使用、哪些需求先验证。
再把界面看清楚
用 storyboard、页面清单和视觉确认减少理解偏差，避免把所有功能堆在一页。
最后小步可回溯
功能拆小、做完验证、记录决策、更新交接，让不同 Agent 接手也不丢上下文。
如何使用
从“开始使用”出发，Agent 会判断接下来该走哪一步。
你不需要先判断项目是新的、已有的，还是将来会使用多个 Agent。
统一接入
先识别项目状态，再完成需要的安装、融合与兼容层。
支持 Codex、Claude、Cursor、Copilot、Trae、CodeBuddy、Qoder、Devin 和 Windsurf。多个 Agent 可共享同一套标准；接入后会验证当前 Agent 是否真正激活，每个任务只加载当下需要的规则。
提示词
开始使用 Motux Build
一条主流程
先开始，Agent 再根据项目状态完成正确的分支。
开始使用 Motux Build
先判断项目状态，再选择安装、已有规则融合或已安装项目的续接操作。
- 新项目只安装标准与当前 Agent 的最小桥接；已有项目先盘点规则和冲突。
- 后来增加 Agent 时复用同一份标准，只按需补充新的桥接，不重新安装。
- 根规则、已有规则融合和原生规则仍分别确认，不直接覆盖。
- 完成后明确报告当前 Agent 是已激活、待重载、版本陈旧还是被冲突阻断。
后来增加新的 Agent
新 Agent 优先读取已有的通用兼容层；需要原生规则时才进行小范围补全。
- 默认先生成只读方案，不因为发现工具目录就假定要写入。
- 可在首次接入时选择“发现后提案”“安全自动补全”或“仅通用兼容层”。
- 已有规则、根文件、未知格式和 Qoder CN 始终不自动改写。
只安装 Motux Brief
只把产品发现与决策表单 skill 放入当前项目，不接入完整 Motux Build 标准。
- 适合在其它项目里单独测试 Motux Brief。
- 默认只创建或更新
skills/motux-brief/。 - 安装后由 Agent 生成完整产品发现或聚焦决策的本地表单和 Brief JSON。
安全更新
在固定安全条件满足时一次完成补丁更新；只读检查使用单独的短命令。
- 只检查时不修改项目文件。
- 安全更新会一起更新所有符合条件的补丁组件，不反复确认。
- 任一条件不满足就保持零写入，并给出少量下一步选项。
支持的 Agent
一份标准，多种编程 Agent 共用。
每个桥接文件只告诉 Agent 去读取项目内的 .motux/AGENT_ENTRY.md；完整标准始终只维护一份。
先有通用兼容层
首次接入可建立最小的 AGENTS.md 桥接。需要原生规则的 Agent 再按固定目标补充，不复制整套标准。
按任务加载标准
Agent 先选择当前任务的 Profile，只读取最多三份初始规则；遇到界面、部署等明确阶段时，才加载对应补充标准。
Qoder CN
会识别现有 .lingma/rules，但不会猜测未公开的规则文件格式。当前版本提供冲突检查与人工配置说明。
接入后验证状态
存在 .motux/ 不等于已经生效。Manager 会区分待激活、已激活、版本陈旧和被阻断，并给出下一步。
自动发布
完成一次项目发布配置后，只说明要发布什么。
无需选择发布流程或检查等级。Motux Delivery 会根据 Git 改动、项目配置和既有成功记录， 自动判断发布机制、检查范围和需要确认的风险边界。
直接说出结果
例如部署当前版本到测试环境、发布指定版本到 GitHub，或把已确认版本发布到生产。
自动识别改动
文案与局部样式走更短路径；功能、依赖和全局样式执行标准检查；权限、支付和基础设施从严处理。
完成整段流程
测试部署和 GitHub 发布由一次明确请求覆盖，不再为构建、记录和每个内部步骤反复确认。
只在必要时停下
生产发布最多确认一次；回滚、数据恢复、新目标和新凭据仍会单独说明风险并征求决定。
静态网站
少量文案或样式修改，不再承担容器发布的额外步骤。
项目需先审核固定目录、回退边界和发布脚本。随后，Agent 按这份配置建立隔离候选版本，完成桌面端、移动端、 资源、链接和 HTTP 检查，再执行原子替换并保留回退版本。共享网关和服务器上的其它项目会被列为禁止范围。
Skill 推荐
遇到专门任务时，先看看有没有更合适的工具。
当当前 Agent 存在明确能力缺口，Motux Build 可以从受审核目录中找出兼容的 Skill， 说明适用原因、来源和注意事项。用户同意后才会安装。
按任务触发
只有在前端、测试、文档等具体任务确实需要专门能力时才查询，不在每个任务里打扰用户。
先比较再决定
Agent 先说明为什么推荐、能解决什么问题和可能代价，用户可以安装、跳过或选择其它方案。
来源可追踪
目录记录固定来源、版本和完整性信息；安装不会把未知脚本直接带进项目。
持续更新
先看差异，再决定是否把新经验带进项目。
每个项目会记录已安装版本。更新前，Agent 会告诉你哪些能力变了、哪些文件会受影响，以及是否需要你的判断。
检查
比较当前版本与稳定版，展示变化、风险和兼容性，不改任何文件。
确认
选择更新 Manager、Motux Build 全部、某个 Build 组件，或暂时保持现状。
更新
只替换 Motux 管理的内容，写入升级记录并保留可回退的 Git 提交。
安全边界
运行中项目的重点是“不覆盖、不乱改、先汇报”。
项目规则不覆盖
已有的 AGENTS.md、CLAUDE.md、项目记忆和业务文档仍归项目所有；Motux Build 的新增规则放在
.motux/products/build/overrides/。
先给升级计划
更新前先说明已安装版本、可用更新、受影响内容、验证方式和回退路径；原生桥接更新仍是单独确认项。
不暴露敏感信息
不要把账号、密钥、服务器密码或私钥贴进聊天；需要输入密码时，优先让用户在终端中输入。
更新可回退
每次更新记录在 .motux/updates/，并只提交 Motux 自己的变化，方便查看和回退。
早期版本支持
只在项目已经安装早期 Motux Dev 时使用。
专用支持包会先核验早期版本指纹并生成迁移计划。普通 Motux Build 安装和安全更新不会进入这条流程。
专用提示词
从早期 Motux Dev 迁移