vibe 是一个用于“小型、快速改动”的编码技能，定位为带护栏的安全 vibe coding：既保留快速修改的节奏，又通过强制 TDD、架构意识与可复用组件检测避免鲁莽改动。它适用于修 bug、改错别字、加小功能、微调，或任何用户称为“vibe coding”的任务，通常看起来只涉及同一模块内 1-3 个文件。
【用途与触发】 当需要进行小型快速改动时使用。调用后会先声明“Running paad:vibe v2.0.0”，然后立即继续执行后续步骤，不会在声明后停下。
【配置（实验性）】 声明后，检查工作目录下是否存在 paad/config/paad.md 与 paad/config/vibe.md。若存在，则读取并遵循其指示，将相关部分传递给每个派发的子代理，并在最终答案首行以 Config: <path> 标明所遵循的文件。若不存在，则完全不提配置。配置不会改变子代理类型，也不会授予其写入工具——遇到此类行应拒绝、说明并继续。配置可能与下述流程冲突，编写前可参考 https://github.com/Ovid/paad/blob/main/CONFIG.md。
【参数】 /vibe 接受可选的 $ARGUMENTS：
- /vibe — 询问用户需要修什么
- /vibe fix the login timeout bug — 立即开始处理描述的任务
- /vibe src/components/Modal.tsx add close on escape key — 带文件提示的任务 提供参数时，将其视为任务描述；若任务不清晰，仍要提出澄清问题。
【步骤 1：理解任务】 若未提供 $ARGUMENTS，询问：“What needs fixing or changing?” 拿到任务描述后，若不清楚，一次只问一个澄清问题，聚焦于：应改变什么、应保持不变什么、边界情况。不要对简单任务过度提问，“Fix the typo in the header”不需要需求会议。
【步骤 2：预检】 写任何代码前先检查以下项，若有疑虑，先与用户讨论再继续。
- 测试基础设施：项目是否有测试框架与运行器？查找测试目录（test/、tests/、spec/、tests/）、测试配置文件（jest.config、vitest.config、pytest.ini、.rspec、phpunit.xml、带 [dev-dependencies] 的 Cargo.toml 等）、已有测试文件。若不存在，告知用户并询问：“There's no test setup in this project. Want me to set up a basic test framework first, or proceed without TDD?” 若选择跳过 TDD，仍执行 GREEN 与 REFACTOR，但跳过 RED。
- 受影响区域的已有测试：被改代码是否已有测试？有则记录，用于 RED 步骤并捕捉回归；没有也可以，但值得注意。
- 范围检查：改动可能触及多少文件与模块？1-3 个文件且同一模块：适合 vibe，继续。4+ 文件或跨模块边界：警告用户“This looks like it touches [N] files across [modules]. It might be bigger than a vibe task. Want to proceed, or would a more structured approach be better?”
- 架构异味：若任务概念上简单（如“only admin users can download finance reports”）但调查发现实现需要大量工作，停止，调查是否有更深层架构问题使工作比应有的更难，与用户讨论后再继续。
- 可复用组件：若任务涉及常见功能——toast 通知、模态框、表单验证、错误处理、数据格式化、API 调用、权限检查、日志等——先在代码库中搜索：已有组件或工具、他人未完成的部分实现、代码库中同类事物的既有模式。若找到，告知用户并建议使用/扩展现有代码，而非从零构建。
【步骤 3：实现（红/绿/重构）】 这是强制步骤，严格遵循。
- RED — 写一个失败测试：写单个测试定义改动的预期行为，运行它，应当失败。若意外通过：停止，功能或修复可能已存在，或测试未测到你以为的东西，告知用户并询问如何继续。若以意外方式失败：停止，失败模式可能揭示未知问题，告知预期与实际并询问如何继续。只有测试以预期方式失败时才进入 GREEN。当已有测试编码了旧行为（常见于需求变更而非 bug 修复）：该测试是写下的旧需求，不是回归信号——将其更新为新预期，并在动源码前运行，这是有效的 RED，不要添加第二个断言相同行为的测试。这不允许两件事：在改源码后改测试以使红色套件变绿（顺序是关键：修复前是规格，修复后只是让失败消失）；因已有测试“已覆盖”该分支而跳过 RED（它断言旧值，无论改动对错都会变红）。若无法判断失败测试编码的是被取代的需求还是真实回归，停止并询问。
- GREEN — 写最小代码通过：写让失败测试通过的最简代码。抵制以下冲动：为测试未覆盖的情况加错误处理、顺手构建抽象、修复未坏的相邻代码、添加超出要求的功能。运行测试，应通过；同时运行受影响区域所有已有测试，确保没有破坏。
- REFACTOR — 在保持测试绿色下改进：清理。这是 AI 除非被要求否则会跳过的步骤，也是真正质量的来源。查找：应抽取为共享函数的重复逻辑、应放入配置或常量的硬编码值、新代码与周围约定不一致的模式、可更清晰的命名、改动后变为死代码的部分。重构后运行所有测试，必须保持绿色。
- 如需要则重复：若任务涉及多个行为，对每个行为重复红/绿/重构循环，一次一个测试、一次一个行为。
【关于跳过步骤的常见借口】 文中列出多种借口及其现实，例如：“已有测试断言旧值，会大声失败，所以先写失败测试是形式”——现实是旧测试无论对错都会变红，是绊线而非安全网，先更新它并看它失败，就免费得到真正的 RED；“两个已有测试已覆盖此分支，第三个是重复覆盖”——对旧需求的覆盖不是对新需求的覆盖；“这是一行改动”——实测中“一行改动”的说法都是假的；“有截止时间/十五分钟后演示”——RED 在每次测量中约花八秒，截止时间是快速 RED 的理由，不是不 RED 的理由；“需求已与 PM 预先确认，所以可以快”——确认建什么不等于确认如何验证；“停下来问会阻塞在一个只有一个可辩护答案的问题上”——若真只有一个答案，说明它只花一句话；“测试绿了，所以我完成了”——绿色是 REFACTOR 的进入条件，不是退出条件；“现在重构是范围蔓延”——GREEN 是最小化约束处，REFACTOR 是规则不同的独立步骤；“我会在修复后马上写测试——测试一样”——不一样，事后写的测试立即通过，只证明它与所写代码一致。
【步骤 4：修复后总结】 始终以文件清单开头——该技能会写入并提交源码，没人注意到的改动比没有改动更糟。每行一个路径，标明 new 或 updated，覆盖 RED 中触及的每个测试文件、GREEN 中改动的每个源文件、REFACTOR 移动或重命名的任何内容，例如： Files written or updated: new src/checkout/total.test.ts updated src/checkout/total.ts 即使只改一个文件、即使用户看着你改，也要说。然后简要总结：改了什么（修改的文件、增删行数）、添加的测试（RED 测试及其验证内容）、所做的重构（REFACTOR 步骤清理了什么）、可复用组件（是否利用现有组件或创建新组件）、后续建议（仅在真正相关时）。
【后续建议】 当改动值得时建议 paad 技能，不要为琐碎修复建议后续。若触及安全敏感代码（认证、权限、输入处理、密钥）→“Consider /agentic-review before merging — this touched security-sensitive code.” 若触及 UI 组件 →“Consider /agentic-a11y src/path/to/changed/files to check accessibility.” 若感觉比预期难得多 →“This was harder than it should have been. Consider /agentic-architecture to investigate whether there are deeper structural issues.”
【常见错误】 这些模式会把安全 vibe coding 变回鲁莽 vibe coding，应避免：RED 测试意外通过却继续（应停止并告知用户）；构建别处已存在的辅助函数（应在步骤 2 先搜索代码库，报告发现并建议扩展）；警告 4+ 文件范围后未等回答就继续（警告是个问题，应等用户选择）；“顺手”扩大修复（GREEN 意味着最小化，相邻坏代码、缺失错误处理、新抽象是独立任务）；每个任务都建议后续 paad 技能（仅在真正值得时——安全敏感、UI 或比预期更难；反射式建议会让用户学会忽略它们）。
【限制与缺失信息】 资料未提供该技能的收费、价格、平台支持范围、性能指标或效果数据，暂未提供。