check

check 技能概览

check 技能能做什么

check 技能是一套面向代码 diff、PR、issue 分流、发布就绪、push 以及项目审计的 review + gate 工作流。它最适合想快速但严谨地回答这类问题的用户：“这个能安全发布吗？哪里有问题？在合并之前我该先修什么？”

这个技能最适合什么场景

当你需要对一个明确的变更集做代码审查时，就该用 check 技能，包括合并前、发布前，或在验证生成产物和后续动作是否到位时。它尤其适合你希望 agent 先检查 worktree、避免隐藏的本地改动，并把可修复的问题与需要人工确认的事项分开处理的场景。

check 有什么不同

check 技能不是一个泛泛的“看看这段代码”提示词。它对 dirty 或未跟踪的 worktree 设有明确的安全门槛，遵循清晰的 review-first 工作流；当存在架构或安全风险时，还会路由到对应的专家 review。相比一次性的 check for Code Review 提示，它更强，因为它减少了“何时检查、检查什么、什么时候停下”的猜测成本。

如何使用 check 技能

安装并触发 check

安装方式：

npx skills add tw93/Waza --skill check

然后在你有明确审查目标时调用它：例如 diff、分支、PR、release candidate、commit 范围，或者 repo 审计请求。对于 check usage，请给 agent 一个具体范围，比如“审查最近 3 个 commits”，“在合并前检查这个 PR”，或者“依赖更新后审计发布就绪情况”。

给技能提供正确的输入

check 最强的输入不是“这个好吗？”，而是带上下文、边界清晰的任务。好的示例包括：

• “在合并前检查这个 PR 是否有安全和架构回归。”
• “审查当前 worktree，告诉我哪些问题会阻碍发布。”
• “审核生成文件，判断它们是否与源代码变更一致。”

请带上分支、commit 范围、目标发布版本，以及诸如“不要修改文件”或“只查看公共 repo 上下文”这类约束。这样可以帮助技能避免变成宽泛、空泛的 review 行为。

先读这些文件

先看 SKILL.md，再检查 references/project-context.md 和 references/persona-catalog.md，以理解 review 深度、专家路由以及发布预期。只要 diff 触及信任边界、API、imports 或模块结构，就应使用 agents/reviewer-security.md 和 agents/reviewer-architecture.md。如果工作流包含对 issue 或 PR 的维护者后续回复，references/public-reply.md 也很重要。

实用工作流建议

在 review 之前，这个技能期望先执行一次 worktree 安全检查：git status --short --branch -uall。这一步很关键，因为 dirty 或未跟踪的改动会改变 review 的含义。如果你想让 check guide 的结果更好，请明确告诉 agent：它是只报告发现，还是也可以修复安全问题；以及修改完成后应该使用什么验证命令。

check 技能常见问题

check 只用于代码审查吗？

不是。check 技能也覆盖发布就绪检查、push、已发布产物、issue 和 PR 分流，以及项目级审计。只要任务包含“上线前”的判断，而不只是读代码，它就比普通提示词更合适。

什么情况下不该用 check？

不要把 check 用在开放式想法探索、根因排障，或文案编辑上。这个技能是为具体 diff 和操作性 review 设计的，不适合头脑风暴或叙事性反馈。

check 适合新手吗？

适合，只要你能说清目标对象和结果。新手只要准确说明改了什么、希望 review 什么、以及只要发现问题还是也希望顺手修安全问题，通常就能得到最好结果。如果缺少这些信息，check install 也许不难，但 check usage 会变得过于宽泛，难以可靠使用。

它和普通提示词有什么区别？

普通提示词通常是在做主观 review。check 增加了一条更严谨的路径：安全预检、范围控制、验证预期，以及针对安全或架构问题的专家路由。对 check for Code Review 来说，这让它比临时性的 review 请求更可靠。

如何改进 check 技能

提供更紧的 review 简报

最有价值的输入包括：改了什么、为什么改、什么不能出问题，以及你希望得到什么类型的 review。比如：“只审查认证路径”，“重点看发布产物”，“检查这个 refactor 是否改变了 public APIs”。这样可以缩小搜索范围，提高信号质量。

明确硬性约束

告诉技能打包规则、生成文件、受保护路径，以及必须执行的验证命令。如果仓库里有构建或发布的单一事实来源，也请提前说明。这样可以减少过度自信，帮助 check 技能发现漂移、缺失产物或不安全的后续动作。

根据发现迭代，不要根据表扬迭代

第一轮结束后，直接回复你要复查的具体发现，或者你已经应用的补丁。这个技能在你一次只针对一个风险点做第二轮检查时会表现更好，比如安全、架构或发布就绪。如果输出显得太宽泛，就缩小范围，而不是只要求“更多细节”。