安装
npx skills add tw93/Waza -a claude-code codex cursor -g -y适合谁
如果你已经会做功能计划和修缺陷，只是希望智能体按同一套习惯跑，而不是临场发挥，这个技能对得上。官方把它写成：把你已经熟悉的工程习惯，变成智能体可以执行的技能。
安装后会得到一组斜杠技能，页面点名 /think、/check、/hunt。Claude Code 里直接打斜杠命令；Codex 里按已安装技能的名字调用，并走同一套步骤。页面还写到 Cursor、Gemini CLI、Copilot、Amp、Kimi Code CLI，以及会读取同一共享目录的其他智能体也能捡起这八个技能。这是目录读取关系，不是一份互斥名单。
更合适的人是：手头有一个可打开的目标仓库，想先做只读计划或检查，而不是一上来让智能体 implement。官方说明见
https://github.com/tw93/waza
3 分钟完成第一次尝试
只走这一条官方安装路径：
npx skills add tw93/Waza -a claude-code codex cursor -g -y
命令会把一份副本落到 ~/.agents/skills 这个共享技能目录。Claude Code 以符号链接接入；Codex、Cursor 以及其他会读该目录的智能体再把技能识别成 /check、/think 等名字。页面没有另给第二套安装器作为主路径。
前置：本机已能运行上述 npx 命令，并且至少打开了一个会读取 ~/.agents/skills 的智能体。安装位置就是这个共享目录，不要再手工复制到别的文件夹。
第一次任务选可逆、偏分析的动作。在 Claude Code 打开目标仓库后输入 /check，或先输入 /think 只做计划；在 Codex 则按技能名调用同一套检查或计划。不要在第一次就说 implement。成功信号：技能以 /check、/think 等名字出现，并且 /check 能基于仓库公开上下文给出检查结果，而不是提示技能未安装。
使用案例
案例一：先计划功能，再决定是否实现。
官方把规划功能写成：/think，得到计划后批准，再说 implement X，然后 /check，最后才 merge。第一次只跑到 /think 并阅读计划；证据没有写批准按钮长什么样，也没有写 merge 的具体命令，能确认的是这条顺序，以及实现应发生在计划被接受之后。
案例二：先查根因，再改代码。
官方把修缺陷写成：/hunt，再修复，再 /check，然后才做后续跟进。页面把跟进写成 release/publish/push/issue follow-through，但没有展开这些跟进步骤。第一次只跑 /hunt，确认根因描述对得上现象后，再动手改。/hunt 被写成用来确认根因，而不是直接开改。
两次都建立在同一条安装路径上。/check 可以接在计划或修复后面，但第一次仍应单独跑检查，确认它读到的是公开上下文。
使用边界
Waza 只提供通用工程习惯。/check 会在运行时读取目标仓库的公开上下文，包括 README、包清单、Makefile、持续集成工作流，以及你这次任务的约束；它不会读取私有路径、凭证或令牌。页面没有写它可以访问私有配置或密钥。
安装命令里带了 claude-code、codex、cursor 三个目标，副本落在 ~/.agents/skills。其他会读该目录的智能体也能捡起技能，但页面没有为每一个名字单独给触发示例。除 Claude Code 的斜杠和 Codex 的按名调用外，其余环境能确认的只有“读到共享目录就会出现这八个技能”。
页面没有写语言范围、配额或必须在哪个仓库类型上使用。缺少目标仓库的公开上下文时，/check 能做到哪一步，官方没有另给失败样例。