Vibe Build
一个完整的构建工作流，由 Agent 自主运行。用户做产品决策；你（Agent）做流程决策。永远不要要求用户解释工作流——直接遵循它。仅在关于构建什么、偏好和关卡审批时询问用户。
唯一规则
产品决策 = 用户输入。流程决策 = 你的。在询问用户任何事情之前，先检查它是否属于产品决策。如果不是，请自行决定并继续前进。
阶段 0 — 初始化（仅适用于新项目）
- 确定技术栈。如果项目完全未定义，请恰好问一个问题：”我们应该构建什么？（一句话就够了）“。不要进行面试式的提问。
- 自行研究技术栈：当前框架版本、推荐设置和标准项目布局，使用网络搜索和框架文档。将决定总结在最多 5 行内——不要向用户粘贴长篇的研究内容。
- 在项目根目录中根据 references/agentsmd-template.md 中的模板编写
AGENTS.md。这是项目的宪法：后续每个阶段在进行结构性决策前都会读取它，因此用户无需重新解释约定。 - 安装项目需要的临时技能（最多 5 个），遵循 references/temp-skills.md。如果项目很简单或者你现有的技能已经覆盖，则完全跳过技能安装。
- 在 ≤ 15 行内报告初始化结果，呈现你提议的编号计划，并在编写任何项目代码之前等待审批。
阶段 1 — 规划
- 制定一个编号的、有范围限制的计划。将你可以在一个会话中完成的小任务明确列出，并显式推迟其他项。
- 获得明确的审批。如果用户修改了计划，那么修改后的版本胜出。
- 谨防交错：不要在该计划的讨论仍然开放时开始构建。
阶段 2 — 构建
- 对于适合项目的场景，遵循测试纪律：逻辑部分要写测试，一次性胶水代码可以手动检查。不要为简单的构建发明重型测试框架；也不要漏掉可能导致 Bug 的逻辑测试。
- 保持最小依赖。每个依赖都是用户继承的负债——除非有明确的好处，否则优先使用标准库或零依赖。
- 在进行每个结构性决策前检查
AGENTS.md。以小而命名清晰的步骤提交代码，以便工作可以被二分查找（bisectable）。
阶段 3 — 验证（在声称“完成”之前）
运行项目，然后证明它正常工作：
- 有 UI → 在真实浏览器中点击测试（使用 Playwright 或 Agent 的浏览器工具），检查控制台错误，验证端到端的主流程。
- Web UI → 审计可访问性和交互质量（焦点状态、表单、暗黑模式、触控）：使用可用的设计准则审查技能，否则自行检查。
- 涉及到认证、机密、支付或用户输入 → 进行安全审查：输入验证、秘密处理（绝不提交机密；使用环境变量替换）、最低权限默认设置。
- 在做出断言之前提供证据：报告运行了什么以及通过了什么，或者承认失败并先修复。
阶段 4 — 发布
- ”部署/上线/预览链接“ → 通过项目文档记录的路径进行部署。对于托管在 Vercel 的项目，git-push 到已链接的项目，在没有登录信息时回退到
vercel deploy --temporary，并返回 URL。 - Pull Request：简洁的描述内容——变更了什么、为什么、如何测试——而不是差异叙述。
- “完成”的提交意味着构建和测试在刚刚收集的证据上通过了。
阶段 5 — 临时技能清理
临时技能（阶段 0 步骤 4）是项目范围的。在项目结束时，或者当某个临时技能被证明广泛有用时，建议将其提升到用户的共享技能目录（或删除它）。绝不能让临时技能静默地变异为永久性的全局安装。
Token 节俭（所有阶段）
只读取最小且足够的文件范围；不要重复读取你已经看过的整个文件。完成一个阶段后总结一次，而不是叙述每一步。优先执行脚本和工具，而不是将它们的内容粘贴到聊天中。让技能通过触发器懒加载——永远不要将技能内容转储到对话中。
参考资料
- references/agentsmd-template.md——在阶段 0 步骤 3 期间阅读并填充。
- references/temp-skills.md——在阶段 0 步骤 4 期间，安装任何临时技能之前阅读。