很多人刚装完 Waza 就想着让 Agent 全程自动跑，其实这用法不对——它更适合搭一套人工触发的工程工作流：你在关键节点调用对应技能，Agent 就只在这个技能的边界里干活，干完就停，下一步怎么走全由你定。

工作流一：从需求到实现

做新功能的时候，先敲 /think。让它先质疑需求、抠设计细节、列清楚风险点和验证用的命令。等你确认整个计划没问题了，再让 Agent 正常写代码实现。实现阶段就别一直开着 /think 了，不然本来做计划的技能会被当成执行技能用，节奏反而容易乱。

工作流二：从异常到根因

碰到报错、功能回归、以前好好的现在用不了这类问题，直接丢给 /hunt。它的核心逻辑是先把症状、复现步骤、根因和验证方法串成完整链条，再动手修。千万别让 Agent 上来就“试个补丁看看”，尤其是渲染、状态、缓存、构建输出这类问题，靠猜着修很容易越修越乱。

工作流三：从完成到交付

任务收尾的时候用 /check。它会对照 diff、项目约束、验证证据和发布风险来排查问题。要写文档、文章、发布说明就切 /write；读 URL 或者 PDF 先用 /read；要研究陌生领域的内容就接 /learn。

插件和共享安装怎么配合

README 里既给了共享 skills 的安装方法，也给了 Claude Code 和 Codex 的原生插件（native plugin）安装路径。共享安装适合多个 Agent 共用同一份 Skills 的场景；插件安装则适合跟着宿主工具一起更新的情况。团队里最好统一用一种主安装路径，不然排查“为什么我这边触发不了 Waza”的时候会特别麻烦。

最后给大家列个检查清单：能不能正常触发技能名，能不能看到八个技能目录，知不知道更新命令，有没有在项目规则里说明什么时候用 /think、/hunt、/check。这四项都齐了，Waza 才真的变成 AI 编程 Agent 的工程工作流，而不是又一份扔在那儿吃灰的文档。