solopowers-receiving-code-review
一份指导开发者如何在收到代码审查反馈后正确回应的技能:先验证再实现,先提问再假设,以技术正确性优先于社交客套,并给出对外部审查意见保持审慎核查的具体流程。
找到适合任务的 Agent Skill,阅读介绍并复制安装命令。
更新于 10-31 00:15
12,974 个结果
一份指导开发者如何在收到代码审查反馈后正确回应的技能:先验证再实现,先提问再假设,以技术正确性优先于社交客套,并给出对外部审查意见保持审慎核查的具体流程。
一套系统化调试技能,要求在提出任何修复前先定位根因,适用于缺陷、测试失败、构建失败、性能与集成问题等各类技术故障,并给出四阶段流程与常见错误自查。
通过交互式追问、代码库排查与测试场景建议,自动整理并创建清晰的 GitHub Issue,需使用已认证的 gh CLI。
Artifact Proof 是一个用于验证构建产物(built deliverable)的技能,适用于生成 ZIP、安装程序、可执行文件、wheel、软件包、发布资产等交付物之后的质量校验。其核心规则是:源码树中的测试不能证明构建产物本身可用,必须测试用户实际收到的文件。该技能要求在构建完成后计算校验和并记录版本/源码修订号,将产物解压或打开到全新目录,检查必需文件是否存在以及是否混入禁止文件,从解压后的产物中运行真实的用户入口点,运行产物自带的 doctor/自检,验证内部清单/校验和与版本信息,并针对解压副本而非源码树重复关键测试。对于归档文件需验证 CRC 与路径往返,对于二进制需执行版本/自检,对于安装程序需在适用时验证安装与卸载/修复行为。若产物本身未被打开并实际运行,应将其行为标记为未验证,不能仅因编译、lint 或仓库测试通过就宣布发布就绪。
该技能用于对单文件 C 游戏进行回归测试。这类游戏通常是一个包含大量 static 声明的大型 .c 文件,并附带一批 *_test.c 测试文件,这些测试文件会被直接编译进游戏源码中。测试运行器通过 glob 匹配 *_test.c,因此只要把新的测试文件放入 source/ 目录,就会自动加入测试套件。技能涵盖测试文件结构、编译规则、模拟世界夹具、卡住的模拟测试调试方法以及相关纪律要求,适用于 Aeons Echo: Null Citadel 系列及未来同类原生 C 游戏。
check-work 是一个变更后验证工作流技能,用于在实现完成后独立检查代码差异、运行真实的构建与校验工具,并判断所请求的工作是否真正完成。它不替代实现规划或领域专属验证,而是聚焦于交付前的核验环节:重读任务完成标准、审查完整 diff、识别范围蔓延或占位内容、运行项目定义的构建/编译/测试/lint/包校验、比对公共接口与配置一致性、检查负向用例,并将结果写入 VALIDATION.md。适合开发者在提交或发布前用作独立质量闸门,输出结构化的 PASS/FAIL 结论。
Compatibility Matrix 是一个用于管理兼容性问题的技能,核心观点是:兼容性是一个矩阵,而不是单一版本号。它要求列出所有可能改变行为的维度,包括操作系统、架构、Shell、运行时/工具版本、模型/提供商、协议/Schema 版本以及相关可选组件,并将每种组合标记为支持、不支持或未验证。该技能强调针对高风险交叉组合(尤其是最旧的受支持运行时与最新的协议/依赖)选择代表性组合进行自动化测试,不应把 Linux/Python 的通过结果外推到 Windows PowerShell,也不应把一个提供商的 MCP Schema 外推到另一个。兼容性声明需与证据绑定,边界变化时更新矩阵;未实际验证的组合应标注为未验证,而非假定兼容。
Edge Case Matrix 是一个用于指导边界条件测试设计的技能,适用于修改解析器、安装器、API、输入处理、文件处理、状态机或包含大量边界条件的代码时。其核心规则是:从输入维度推导测试,而不是依赖眼前恰好出现的示例。该技能提供了一套最小矩阵,针对每个相关边界考虑正常、空、缺失/空值、单项、多项、最小值/最大值、无效类型、语法错误、重复值、重排序值、空格/Unicode、旧/新版本、权限失败、超时、部分状态和重跑等情形。当维度相乘时建议使用成对组合,仅对小型高风险状态空间保留完整笛卡尔覆盖。对于有状态操作,需包含步骤间中断和从部分写入状态恢复;对于解析器,需包含未知的未来字段;对于安装器,需包含已安装和安装损坏的情况。其目标不是最大化测试数量,而是在用户之前识别出性质不同的失败类别。
这是一个面向软件安装、更新、迁移、下载、写文件、网络调用等可能产生部分失败与状态损坏场景的故障注入测试技能。它强调仅靠正常路径测试无法验证恢复能力,要求在发布具有破坏性或带状态的自动化之前,主动注入真实故障。核心覆盖网络超时、下载截断、依赖不可用、权限拒绝或只读目标、畸形输入、磁盘写入失败或部分解压、子进程非零退出、备份与提交之间中断、上次部分运行后重试等最小矩阵。每类注入都要求清晰的非零失败、保留原有状态、可操作的诊断信息与安全重试路径,并确认临时文件和进程已清理,同时不得为让注入失败通过而削弱生产检查。
Failure Recovery Loop 是一个用于可靠处理失败与重试的技能,适用于测试、构建、安装、CI 任务、工具调用或反复尝试失败后仍需继续推进任务的场景。其核心规则是把失败视为证据:保留失败信息、定位根因,并一次只改变一个因果变量。该技能提供一套循环流程:捕获精确命令、输入、退出码、stderr/日志与相关状态;对失败进行分类(环境、依赖、语法、逻辑、数据、时序、权限、兼容性或外部服务);提出一个可证伪的原因假设;构造能区分该假设的最小复现;做最小因果改动;重跑复现,若仍失败则修正假设而非叠加猜测;变绿后运行原始失败命令及完整门禁;最后清扫共享同一根因的同类路径。它强调在理解证据前不得清除证据,不得仅为让流水线变绿而把必需失败降级为警告,没有因果改动的重试不算调试。
Minimal Reproducer 是一个用于排查疑难缺陷的技能,适用于 bug 间歇性出现、结构复杂、跨层调用,或深埋于大型应用中、尚未定位到因果输入或边界条件的情况。其核心规则是:不断缩减失败场景,直到只剩一个受控变量能够解释正常行为与故障行为之间的差异。做法是从真实的失败路径出发,构建仍能复现症状的最小案例,逐一移除无关的文件、插件、配置、数据和时序假设,同时保留可能构成因果关系的真实边界,例如实际的解析器、shell、序列化器、协议或文件系统行为。当案例达到最小后,每次只改变一个因素并记录结果;若复现器因其他原因失败,则说明它没有价值。在条件允许时,可将最终案例保留为回归测试夹具,使该缺陷易于理解,并避免其被悄无声息地重新引入。
该技能针对测试中大量使用 mock 模拟子进程、文件系统、解析器、数据库、网络、CLI、序列化或操作系统与云服务等外部边界的场景,强调 mock 只能用于注入故障,无法证明真实边界的行为符合假设。它要求在每一个重要边界上至少保留一个使用真实解析器、运行时、CLI、文件格式或忠实本地测试夹具的集成测试;仅在直接调用某行为不切实际或不安全时才使用 mock。它建议团队追问:当此测试仍然通过时,哪些生产变更可能导致它失效?若答案涉及参数引用、编码、数据结构、退出码、文件锁、协议协商或工具发现,就应补充边界测试。测试需同时覆盖成功路径和最重要的失败模式,并断言输出与状态,而非仅断言 mock 函数被调用。适用于涉及外部集成的质量保障工作流,帮助避免发布版本在虚构接口上通过、却在真实环境中暴露问题。具体安装方式与调用命令暂未提供。
regression-sweep 是一个用于回归测试与缺陷排查的 AI 技能,适用于修复某个缺陷或共享行为、数据结构(schema)、辅助函数、安装器以及跨服务商集成发生变更后,开发者需要检查周边代码是否出现同类回归的场景。其核心规则是:当缺陷源自被修改的共享边界时,它往往不会孤立存在。在直接相关的回归测试通过后,应继续搜寻具有相同模式的兄弟路径。该技能要求先命名底层故障类别,而非只描述表面症状;随后在调用方、复制代码、服务商变体、序列化器、文档片段、测试与生成产物中搜索相同构造;补充一个当因果缺陷再次出现时就会失败的回归测试;测试相邻输入,包括空值、多值、空格/Unicode、旧版/新版、缺失依赖与重复运行;并在修复兄弟路径后重跑范围更广的检查。示例场景包括:一处 ANSI 解码读取意味着应检查所有 PowerShell 读取-修改-写入操作;一处过期版本字符串意味着应核查每一个声明版本的表面;一处错误的子进程参数形态意味着应检查所有同类子进程调用。该技能同时强调不要不加确认地盲目“修复所有相似之处”,而应先确认共同原因再进行编辑。
Requirements Traceability 是一项用于多部分需求实现与验收的技能,核心规则是每条实质性需求都必须对应明确的实现位置和独立证据。它通过追踪表记录“需求→所属文件/组件→测试/门禁→产物/运行时证明→状态”,并要求纳入反向需求(如不得覆盖配置、不得要求手动设置)与平台约束。完成前需逐行核对追踪表;测试套件仅对其实际断言的需求提供覆盖,全部通过并不代表未列入的需求已被实现。范围变更时先更新表格,无法在当前环境验证的需求需明确标记为待验证并指出能证明它的具体门禁。适用于规格、迁移、发布、审计或验收测试驱动类任务,防止以“主要功能已实现”替代完整用户请求。
Skyrim 崩溃诊断技能,用于排查《上古卷轴5:天际》在启动、加载、存档或运行阶段的崩溃问题。它要求提供完整崩溃日志、游戏运行时与崩溃记录器版本、plugins.txt、loadorder.txt、模组管理器列表、SKSE DLL 清单及版本、近期增删更新与生成输出、复现点与频率等最小证据。方法上先识别日志格式与崩溃阶段,分离异常、出错指令、寄存器、调用栈、可能对象、已加载模块与插件列表,将日志与近期变更和版本兼容性关联,检查缺失主文件、不兼容运行时 DLL、过期行为输出、坏资源、无效 FormID 及存档特定状态,最终给出带正反证据的排序假设列表,并推荐最小可逆隔离测试。
该技能为 SPID、KID、SkyPatcher 和 BOS 输出提供跨框架的静态与语义校验。它通过命令行脚本对框架配置进行验证,覆盖 SPID、KID、BOS 及源锁定的 CDF 规则,并包含验证器分歧处理协议。适用于需要检查 Skyrim 模组框架配置正确性的场景,但静态验证无法证明表单解析、语义坐标、角色选择、钩子安全或游戏内行为。
该技能用于解读《上古卷轴5:天际》的 SKSE、框架、资源、动画与运行时日志,帮助定位日志所涉组件并避免误判字段、DLL、模组或依赖。核心要求是先记录游戏运行时、框架/DLL 版本、日志文件名、时间戳和生成该行的实际部署文件,保留完整日志行及上下文,识别发出消息的解析阶段或子系统,再对照该组件的源码或文档验证根因。技能强调按字段解析配置而非整行 grep,区分语法拒绝、未解析表单或依赖、可选规则跳过、功能禁用、安全钩子中止、确定性冲突胜者、缺失资源与普通信息噪声;在批量修改前证明根因,并在所属模组源码/输出中做最小可逆修正后重新部署比较日志。还列出 SPID、原生钩子、Community Shaders、缺失动画、BOS、缺失表单与依赖等高风险解读规则,并提供参考案例与保守分析脚本。
该技能是《上古卷轴5:天际》模组发布的最终强制校验关口。在完成实现与 FOMOD 配置后使用,用于在宣布模组完成或可发布前,逐项核验版本、差异、插件头、Papyrus 脚本、运行时配置、原生 DLL、资产、FOMOD、归档、披露等发布条件;输出结构化完成报告与证据链,区分通过、失败、未测试与不适用,并执行 V4 插件母版、框架规则、运行时日志对账、管理器记账文件与校验器完整性等多重检查。
该技能用于审查测试的“判定依据”(oracle)是否可靠:当测试通过但可能检查了错误信号、用 mock 验证自身假设、对不稳定输出做快照,或无法区分正确与错误行为时使用。核心规则是:只有当用户可见契约出错时测试会失败,测试才有价值。在信任一个绿色测试前,需指出一个应当使其失败的真实生产缺陷;若测试仍通过,则应加强观察边界,优先使用最终状态、解析后的输出、退出状态、哈希或真实协议行为,而非“mock 被调用过”。同时需警惕假阳性测试,如空循环、被跳过的断言、宽泛的异常吞没、复现实现缺陷的 fixture,或编码了虚构 API 的 mock。对关键回归,可临时变异或回退修复,确认测试变红后再恢复并重跑为绿;从未展示过失败的测试是弱证据。
升级路径测试(Upgrade Path Testing)是一个用于验证软件发布、安装程序、数据库结构、配置或工具在全新安装与从旧版本升级两种场景下都能正常工作的技能。其核心观点是:全新安装和升级实际上是两个不同的产品,必须分别验证。该技能要求至少覆盖四种测试场景:空配置环境升级到当前版本、受支持的上一版本升级到当前版本、部分配置的旧安装升级到当前版本,以及在当前版本上重复运行当前安装程序。升级过程中需保留用户自有配置、凭据、值得保留的缓存、项目数据及无关文件,仅替换由工具包自身管理的状态;在删除旧数据前先验证迁移,并在新状态通过健康检查前保留回滚与备份材料。最后需将升级后的有效配置与全新安装加上用户有意自定义后的配置进行对比,因为全新安装成功并不能证明升级路径可用。
visual-verification 是一个面向 AI 编码代理的技能,用于在涉及界面外观的任务中落实“看渲染结果”这一验收规则。它的核心主张是:当外观属于需求的一部分时,源码、DOM 结构、CSS、场景树、测试通过和构建成功都不能证明界面看起来正确,唯一有效的证据是实际渲染输出。技能要求代理按“实现→启动/渲染→截图→查看→找缺陷→修复→重新渲染→再看”的循环工作,且最后一次修改之后的查看必须再做一遍。它还提供视觉金丝雀检查(TOOLS\Test-VisionCanary.ps1),用哈希校验确认代理确实读取了像素而非仅生成截图;若无法读取图像,则保留截图并回退到 DOM、可访问性树、计算样式、控制台、网络和元素几何信息,并如实声明视觉验证不可用。技能列出常见的 AI 界面缺陷清单,如元素重叠或裁切、文本溢出、内容被固定栏遮挡、图片损坏、占位符残留、对比度不足、层级错误、横向滚动条、点击无响应等,同时要求测试交互行为而非只看静态首帧,并检查控制台与网络请求。它明确自身是收尾技能而非设计系统,只修复正确性、可用性和明显缺陷,不追求无边界像素完美。分类选测试与质量,因为其用途是渲染结果的验证与缺陷排查。
WhaleHunterHedge v2.0 是一个面向 Hyperliquid 的多空策略:按历史已实现盈亏把交易者分为“聪明钱”(≥100万美元)与“散户”(1万–10万美元)群组,当聪明钱净持仓方向与散户明显背离且持续加仓时,顺势建立多头或空头仓位。
面向集成测试与端到端(E2E)测试的规则技能,提供实现与审查两部分规范:按触发/过程/可观察结果分层验证行为,界定集成测试中 mock 与真实实现的边界,并给出 E2E 执行条件与代码审查清单。
面向仓库的代码质量策略配置技能:先收集并核对实现与评审的验收条件,经用户确认后创建或更新 docs/project-context/quality.yaml。