codex-plan-review
在实施之前,由Claude Code和Codex CLI审查/讨论计划。
把 Skill 的源码、资源快照、README、包体和安装信号放进一个可搜索、可筛选的公开目录。
在实施之前,由Claude Code和Codex CLI审查/讨论计划。
Claude Code和Codex之间就任何技术问题进行对等辩论。双方独立思考,互相挑战,并最终达成共识或明确分歧。
使用Clean Architecture、垂直切片(按功能分页)、signals、OnPush以及ng-zorro的Angular 21独立前端。在创建或重构Angular应用,添加页面、组件、服务、指令、管道,或者当用户提到Angular前端、独立组件或signals时使用。
针对跨项目和语言的代码变更提供有观点的实施指导。在实现功能、修复错误、重构、代码审查或计划变更时使用,当你需要决定变更类型、范围、提取、所有权、约定处理、升级或验证深度时,而不会陷入机会主义的清理或广泛而不明确的重写中。
在撰写或审阅职业文件时使用,包括研究声明、教学声明、多样性声明、简历或个人简介。当用户提到研究声明、教学理念、多样性声明、个人简介、学术简历、教职申请,或需要帮助撰写职业叙述、定位或为学术晋升准备专业文件时调用。
用于检测和防止数据可视化、仪表板、报告或演示文稿中的视觉误导、认知偏差和设计缺陷。当用户提到图表垃圾、误导性图表、截断轴、数据完整性、视觉欺骗、3D图表问题、挑选数据,或需要审核可视化内容的真实性和准确性时调用。
在不确定性下进行快速数量级估算时使用(如市场规模估计、资源规划、可行性检查),将复杂量分解为可估算的部分,用上下限来限定未知数,对战略假设进行合理性检查,或者当用户提到费米估计、信封背面计算、数量级、大致估计、三角测量,或在详细分析之前需要评估可行性时。
在时间紧迫或不确定性下做决策时使用,防止复杂程序中的错误,设计决策规则或检查表,简化复杂选择,或者当用户提到启发式、经验法则、心智模型、检查表、错误预防、认知偏差、满意化,或需要实用的决策捷径和系统性错误减少时使用。
由Claude(4个代理)和Codex进行并行独立审查,随后合并、对分歧点进行辩论,并最终达成共识报告。无需外部插件。
Claude Code和Codex之间关于PR质量及合并准备度的同行辩论。双方独立审查后,进行讨论直至达成共识——不作任何代码修改。
GitHub研究助手。当用户想要分析一个GitHub仓库时使用此技能。分析维度--1) 基本信息;2) 目的,可以用于什么;3) 技术栈,包括框架、语言、算法等;4) 使用方法和示例;5) 技术架构和模块分析
为React项目提供有观点的React组件架构指导。在审查或设计组件边界时使用,决定UI是否应保持内联、成为本地辅助函数、成为组件边界或成为另一种边界类型,将组件分类为展示型、交互型或容器型,应用组合、无头或多态模式,设置打包和所有权规则,或对提供者、页面、表单、加载和错误外壳进行推理。
在调查某事发生的原因时使用,需要区分相关性和因果关系、识别根本原因与症状、测试竞争性假设、控制混杂变量,或设计实验以验证因果声明。当调试系统、分析故障、研究健康结果、评估政策影响,或者用户提到根本原因、因果链、混杂因素、虚假相关性,或询问“这究竟是为什么发生的?”时调用。
在比较多个命名选项时,跨越几个标准,需要透明的权衡分析、需要达成一致的群体决策、在供应商/工具/策略之间进行选择、利益相关者需要看到决策依据、平衡竞争优先级(成本与质量与速度)、用户提到“我们应该选择哪个选项”、“比较备选方案”、“评估供应商”、“权衡取舍”,或者当决策需要有据可依且数据驱动时使用。
当需要明确的质量标准和评分尺度来一致地评估工作、客观地比较选项、设定接受门槛、减少主观偏见,或者用户提到评分标准、质量标准、评估框架、评分者间信度或评定/评估工作时使用。
在为项目定义停止规则、避免沉没成本谬误、设定客观退出标准、决定是否继续/转向/终止计划时使用,或者当用户提到终止标准、退出途径、停止规则、进行与否的决策、项目终止、沉没成本,或需要对何时退出做出有纪律的决策时。
通过将整个代码库(50-500+文件)拆分成模块,在单独的Codex会话中审查每个模块,然后综合跨模块的发现。无需更改运行器。
通过使用reducer和事件创建React UI,作为显式状态转换的投影。在构建多步骤表单、异步操作、跨组件状态、导航集成、实时更新或复杂验证时使用。通过显式状态转换和隔离副作用消除依赖于时间的错误。
实现预提交钩子和GitHub Actions以保证质量。当被要求“设置CI/CD”、“添加预提交钩子”、“创建GitHub Actions”、“设置质量门”、“自动化测试”、“在CI中添加代码检查”,或任何用于代码质量的DevOps自动化时使用。能够检测项目类型并配置适当的工具。
当您需要在系统地缩小到最佳选择之前生成许多创意选项时使用。在探索产品想法、解决开放式问题、生成战略替代方案、开发研究问题、设计实验,或者当您同时需要广度(许多想法)和严谨性(有原则的选择)时调用。当用户提到头脑风暴、构思、发散思维、生成选项或评估替代方案时使用。
在规划高风险的项目(如迁移、启动、战略变更)时使用,这些项目需要明确的规范、主动的风险识别(事前分析/登记)和可衡量的成功标准。当用户提到“计划这次迁移”、“启动策略”、“实施路线图”、“可能会出什么问题”、“我们如何衡量成功”,或者当高影响力决策需要全面规划并带有风险缓解和工具支持时,请调用此规则。
在处理需要简化的复杂系统时使用,识别瓶颈或关键故障点,为了更好的性能重新设计架构或流程,分解那些感觉难以应对的问题,分析依赖关系以理解连锁反应,当用户提到“这太复杂了”、“瓶颈在哪里”、“我们如何重新设计这个”、“关键组件是什么”,或者当优化需要理解各部分如何交互时。
用于通过假设预测失败并反向工作来识别原因来进行压力测试。在信心度很高(>80% 或 <20%)、需要识别尾部风险和未知的未知因素,或者想要扩大过于自信的区间时调用。当用户提到事前分析、回溯、可能出现的问题、压力测试或黑天鹅事件时使用。
用于澄清模糊的边界、定义质量标准、通过反例教学、防止常见错误、设置设计护栏、消除相似概念的歧义、通过反模式细化需求、创建明确的决策标准,或者当用户提到接近的例子、反目标、不应该做的事情、负面例子、反例或边界澄清时使用。