Critical Code Reviewer

核心用法

critical-code-reviewer 是一个面向代码质量极致追求的审查技能，专为需要深度技术把关的场景设计。当用户请求"批判性审查代码""找出代码问题"或"评审 PR"时激活，覆盖 Python、R、JavaScript/TypeScript、SQL 及前端代码。其核心机制包括：

• 对抗性假设：默认每行代码都有缺陷，直到证明其卓越
• 四级严重度分级：Blocking（阻塞级，安全/数据风险）、Required（必须修改）、Suggestions（建议优化）、Noted（轻微问题）
• 语言专属检测：针对各技术栈的深度 red flags，如 Python 的裸 except、JS 的 == 滥用、React 的 effect 依赖谎言等

显著优点

1. 系统性风险扫描：从 3 AM 生产故障视角审视未处理的 Promise、空值、恶意输入
2. actionable 输出：不仅指错，更提供具体修复代码片段和模式建议
3. 认知负荷优化：区分"代码本身的问题"与"上下文缺失的风险"，避免臆断
4. 平衡性设计： genuinely 优秀的代码会获认可，非表演式负面

潜在局限

• 高激活门槛：需用户明确触发关键词，不适合被动代码辅助场景
• 上下文依赖：部分判断需完整代码库视角，片段审查存在盲区
• 团队摩擦风险：严格风格可能与不追求极致的协作文化冲突
• 多语言深度不均：虽覆盖广，但某些小众框架的检测规则可能不完善

适合人群

• 技术负责人进行 PR 把关
• 代码审计、安全审查场景
• 个人开发者追求代码卓越性
• 技术面试中的代码评审环节

常规风险

• 过度审查可能延误交付，需配合"Verify"标记灵活处理
• 自动化工具的误判需人工复核，不应替代团队代码规范共识

核心用法

该Skill模拟一位零容忍的资深工程师进行代码审查，适用于用户请求"批判性审查代码"、"找出代码问题"或PR评审场景。其核心机制包括：

审查框架：采用四层严重度分级——Blocking（阻塞性问题，如安全漏洞、逻辑错误）、Required Changes（必须修改的 sloppy code）、Strong Suggestions（优化建议）、Noted（轻微风格问题）。

对抗性思维：预设"每行代码都有问题"的审查立场，重点关注：未处理的Promise/异常、空值风险、类型安全、竞态条件、XSS/SQL注入攻击面、性能陷阱（如N+1查询）等。

语言专项检测：

• Python: 裸except、可变默认参数、全局状态污染
• R: T/F简写、向量化误用、显式循环冗余
• JS/TS: ==滥用、any类型泛滥、useEffect依赖数组错误、key prop误用索引
• 前端: 可访问性违规、布局偏移、prop drilling过深
• SQL: 字符串拼接注入、无限制查询、缺失索引

输出格式：严格遵循Summary → Critical Issues → Required Changes → Suggestions → Verdict → Next Steps的结构，确保反馈可执行。

显著优点

1. 权威方法论：来自Posit（原RStudio）的工程实践，融合了企业级代码审查的严谨标准
2. actionable反馈：不仅指出问题，更诊断"为什么错"并给出具体修复模式
3. 多语言覆盖：同时支持数据科学常用语言（Python/R）与工程语言（JS/TS/SQL）
4. 风险分级合理：区分"会凌晨3点报警"的阻塞问题与风格偏好
5. 自约束机制：承认审查边界（如"无法验证完整代码库"时标记为Verify而非Blocking）

潜在局限

1. 语气刚性："zero tolerance"、"constructively brutal"的定位可能导致对初学者反馈过于严厉
2. 上下文依赖：作为纯文档型Skill，无实际静态分析引擎，复杂控制流分析依赖LLM能力上限
3. 框架更新滞后：特定框架（如React最新并发特性）的红旗模式可能未及时更新
4. 假阳性风险：对抗性假设可能过度标记某些防御性编程模式

适合人群

• 准备进入生产环境的核心业务代码审查
• 安全敏感型项目（金融、医疗、政务）的合规检查
• 技术面试中的代码评估环节
• 希望建立团队代码质量基线的工程负责人

常规风险

该Skill本身无可执行代码，风险极低。主要使用风险在于：过度依赖可能导致团队氛围紧张，建议搭配建设性沟通培训；对大型代码库的全量审查可能产生信息过载，建议增量审查（delta review）策略。