code-crit 是一个 PR 范围的代码审查技能，行为上类似资深 staff 工程师审阅队友的拉取请求：覆盖面广，但对噪声保持克制。它会为改动打分、给出明确的合并结论，并把结果作为评论发到 PR 上。
核心原则是“诚实、高信号”。它要求：不为显得尽责而编造问题，也不因不确定而沉默。噪声被界定为：格式器/检查器已负责的风格挑剔、为凑数制造的问题、无依据的套路化模式匹配、以及反射式的“加个测试/加错误处理”要求。不确定性被视为信号而非噪声——拿不准就提出，作为问题（question）级别呈现，而非当作确定的 bug 断言。它还鼓励系统性和前瞻性思考，但需结合本仓库的实际情形论证，而非泛泛的最佳实践。安全方面要求有可信、可达的利用路径才断言漏洞，否则作为问题提出。测试建议仅当逻辑不平凡、出错代价高、且项目有测试文化时才给出。
工作流程：第 0 步定位 PR 并获取 diff，优先使用明确给出的 PR 编号/URL，否则自动检测；无 PR 时回退到分支 diff 并注明跳过发布。第 1 步先建立校准档案：评估项目风险与成熟度、测试文化、本地约定，再明确适用谁的标准——仓库自身约定优先，仓库未规定且属于用户个人项目时应用用户全局标准，绝不把个人口味强加于既有仓库约定。第 2 步并行启动适用的审查支柱（正确性、可维护性、可读性、效率、安全、边界与错误处理、可测试性、标准符合性），每个子代理需要读取支柱规则、校准档案和 diff，并按固定返回契约输出 SCORE 与 FINDINGS（severity、location、issue、fix、certainty）；不适用则跳过，以免制造问题。第 3 步由编排者做二次过滤：去重、删噪声但保留真实疑问与前瞻性关注，按严重度排序，依据参考文档计算评分与结论。第 4 步在终端呈现报告，结论与评分卡在前，findings 按严重度分组。第 5 步若有 PR，则用 gh pr comment 以 --body-file 方式发布同一报告。第 6 步给出后续建议。
限制与注意事项：必须并行启动支柱代理；按改动匹配支柱，不要对一行文案修改跑全部八项；gh 需已认证才能发评论，任何 gh 失败都退化为仅终端输出并告知原因；禁止编辑或删除既有评论。详细评分标准和报告格式存放在参考文件中，本技能文件只作为编排主干。其余信息暂未提供。