尧图网站建设 
code-review 双轴评审用 Standards 与 Spec 并行子代理检查一次 Git diff【免费下载链接】skillsSkills for Real Engineers. Straight from my .agents directory.项目地址: https://gitcode.com/GitHub_Trending/skills13/skills本指南讲解 GitHub推荐项目精选 / skills13 / skills 仓库中code-review技能的设计与实战用法。它把一次 diff 评审拆成两条互不合并的轴——Standards代码是否按本仓库的编码规范来写与Spec代码是否实现了原始 issue / spec 要求的事——并让两条轴各自在独立的子代理中运行。读完本文你将掌握如何确定评审的固定点fixed point、如何定位 spec 与规范来源、如何解读并行子代理产出的双块报告以及如何在 Claude Code 中规避它与内置/code-review的命名冲突。它做什么对HEAD与固定点之间的 diff 做双轴评审code-review的核心动作是评审HEAD与一个由你指定的固定点之间的 diff。固定点可以是任意 Git 引用一次提交commit、一个分支branch、一个标签tag、main或像HEAD~5这样的相对位置。评审沿着两条互不相干的轴进行轴问题读取的内容报告的内容每条发现引用StandardsIs it built right代码写得对吗仓库文档化的规范 smell 基线文档化的违规可能为硬性与代码坏味道始终是判断规范文件及其规则或具名 smell 加上对应 hunkSpecIs it the right thing做的是正确的事吗发起该工作的 issue 或 spec缺失或部分实现的需求、范围蔓延scope creep、实现错误的需求spec 的对应行两条轴永不合并、永不重排。报告以每条轴各自的最严重问题收尾并拒绝在两条轴之间挑一个“总冠军”。原因是一次改动可能一条轴通过、另一条轴失败——完全遵守仓库约定却实现了错误功能的代码Standards 通过而 Spec 失败精确实现了 ticket 要求却破坏了仓库约定的代码则恰好相反。如果强行合并成一个结论通过的那条轴就会掩盖失败的那条轴。技能仓库中的实际定义skills/engineering/code-review/SKILL.md把这条设计原则写得很清楚A change can pass one axis and fail the other: code that follows every standard but implements the wrong thing → Standards pass, Spec fail. Code that does exactly what the issue asked but breaks the projects conventions → Spec pass, Standards fail. Reporting them separately stops one axis from masking the other.技能在 Claude Code 中通过name: code-review的 frontmatter 与description被模型识别见 SKILL.md 的 frontmatter同时配有最小化的openai.yaml界面声明display_name: Code Review、short_description: Review a diff on standards and spec见 agents/openai.yaml使技能也能在其他兼容 harness 中以统一元数据形式被加载。何时使用它输入/code-review即可调用当用户要求评审一个分支、一个 PR、进行中的工作或任何“自从 X 之后”的改动时Agent 也会自动选择它。技能本身在engineering目录的 README 中被列为“模型可调用”Model-invoked技能与tdd、diagnosing-bugs等并列。原文档给出了一张“按场景选工具”的对照表你的情况应该用存在一个 diff你想知道它是否建得对built right且是正确的事the right thingcode-review你想在 diff 里猎杀 bug空指针路径、竞态、off-by-one用 Claude Code 自带的评审注意下文的命名冲突不是这个技能还没写任何东西想测试先行地写出来tdd一整个 spec 需要被构建含评审环节implement它自己会调用本技能整个代码库都漂移了而不仅仅是某个 diffimprove-codebase-architecture有东西坏了但不知道原因diagnosing-bugs固定点必须由你提供。如果你不提供技能会要求你给出一个而不是自行猜测在派生任何子代理之前它会先确认引用可以被解析git rev-parse fixed-point并且 diff 非空——因此一个打错的分支名会在你面前直接失败而不是在两个子代理内部炸开。这一“先验证后执行”的顺序在 SKILL.md 的 Process 步骤 1 中有完整描述。前置条件两条轴各自的输入要求Standards 轴不需要任何前置配置。它读取仓库中所有文档化了“代码该怎么写”的文件——CODING_STANDARDS.md、CONTRIBUTING.md等——并在仓库没有文档化任何规范时回退到内置的 smell 基线。Spec 轴要求存在一个 spec 并且能被找到。查找顺序如下提交信息中的 issue 引用#123、Closes #45、GitLab 的!67通过docs/agents/issue-tracker.md中的工作流获取你作为参数传入的路径docs/、specs/或.scratch/下与分支名或特性名匹配的 spec 文件直接问你。第 1 步依赖docs/agents/issue-tracker.md该文件由setup-matt-pocock-skills技能写入。如果这个文件缺失只要你手动传入路径Spec 轴依然可用。如果根本没有任何 specSpec 子代理会被跳过报告会明确写“no spec available”而不是凭空编造需求。关于 issue tracker 的实际形态setup-matt-pocock-skills支持 GitHub、GitLab、本地 Markdown 等多种后端见 setup-matt-pocock-skills/SKILL.md。以 GitHub 为例issue-tracker-github.md 规定用gh issue view number --comments获取 ticket 内容、用gh issue list --state open --json number,title,body,labels,comments ...列出 issue并提示 GitHub 中 issue 与 PR 共享编号空间#42可能是任一种需要用gh pr view 42尝试解析后再回退到gh issue view 42。若采用本地 Markdown 后端则按 issue-tracker-local.md 的约定spec 是.scratch/feature-slug/spec.mdticket 是一文件一个 issue。Spec 轴的查找顺序正是顺着这些约定设计的。两条轴的核心规范优先 十二种 Fowler 坏味道基线一个不了解你规范的通用评审技能正是这套设计要避免的东西它会把你代码库里有意的选择当成问题标记出来却漏掉你的代码库真正依赖的不变量。因此Standards 轴把仓库自身的文档当作主要来源primary source并且仓库永远优先the repo always overrides。在仓库规范之下的是smell 基线smell baseline——来自 Martin Fowler《重构》第 3 章的十二种代码坏味道。每条 smell 都是一个“标了标签的启发式”如“possible Feature Envy”永远不是硬性违规每条都以它是什么→怎么修的形式陈述让一条发现附带一个动作而不是一句抱怨。此外任何 linter 已经在强制执行的检查两条轴都会跳过。十二种 smell 完整清单直接取自 SKILL.md 步骤 3Smell识别特征修复方向Mysterious Name神秘命名函数/变量/类型名不能反映其作用或内容重命名若想不出诚实名字说明设计本身不清Duplicated Code重复代码同一逻辑形态出现在改动中的多个 hunk 或文件抽取共享形态两处都调用它Feature Envy依恋情结方法访问另一对象的数据多于自身数据把方法移到它嫉妒的数据上Data Clumps数据泥团同样的几个字段/参数总是一起出现一个待诞生的类型打包成一个类型后整体传递Primitive Obsession基本类型偏执用基本类型或字符串代替值得拥有独立类型的领域概念给概念一个自己的小类型Repeated Switches重复的 switch同一类型上的同一switch/if级联在改动中反复出现用多态替换或两处共享一张映射表Shotgun Surgery霰弹式修改一个逻辑改动被迫散落在 diff 中大量文件里把会一起变化的东西聚成一个模块Divergent Change发散式变化一个文件/模块因多个不相关原因被修改拆分让每个模块只为一个原因变化Speculative Generality夸夸其谈的未来性为 spec 并不需要的需求添加抽象/参数/钩子删掉内联回去直到真实需求出现Message Chains消息链很长的a.b().c().d()导航调用者不该依赖它把遍历藏进第一个对象的一个方法后面Middle Man中间人一个类/函数大部分只是转发砍掉它直接调用真正的目标Refused Bequest被拒绝的遗赠子类/实现者忽略或覆盖了继承来的大部分行为放弃继承改用组合两条绑定规则约束整个基线仓库覆盖基线The repo overrides文档化的仓库规范永远优先当规范认可了基线会标记的东西时抑制该 smell始终是判断Always a judgement call每条 smell 都是带标签的启发式不是硬性违规任何工具已强制的内容都跳过。完整运行流程从固定点到双块报告技能 SKILL.md 的 Process 部分 给出了五步标准流程下面是逐步骤拆解。1. 确定固定点并验证无论用户给出什么固定点commit SHA、分支名、标签、main、HEAD~5都先把它钉住没给就问。随后一次性捕获 diff 命令git diff fixed-point...HEAD # 三点 diff与 merge-base 比较 git log fixed-point..HEAD --oneline三点 diff 是关键git diff fixed-point...HEAD三个点以 merge-base 为基准排除暂存区staged与工作区working-tree的改动。这意味着未提交的工作对评审不可见——必须先 commit、再评审、然后 amend 或补一个 fixup。用两点..的git log列出提交列表则是正确的它给出固定点之后的提交。继续之前先验证git rev-parse fixed-point确认引用可解析且 diff 非空。坏引用或空 diff 应该在这里失败而不是在两个并行子代理内部失败。2. 定位 spec 来源按前文顺序查找提交信息中的 issue 引用 → 用户传入的路径 →docs//specs//.scratch/下匹配分支名的文件 → 问用户。若用户说没有 specSpec 子代理跳过并报告“no spec available”。3. 定位规范来源收集仓库中所有描述“代码该怎么写”的文件CODING_STANDARDS.md、CONTRIBUTING.md等。同时始终携带上一节的十二种 smell 基线无论仓库是否文档化了任何东西。4. 并行派生两个子代理两个子代理并行运行互不污染彼此的上下文。各自 prompt 的构成在 SKILL.md 步骤 4 中有明确规定Standards 子代理 prompt 必须包含完整的 diff 命令与提交列表步骤 3 找到的规范来源文件清单外加完整粘贴的 smell 基线子代理没有其他途径访问它简报Report, per file/hunk where relevant, (a) every place the diff violates a documented standard: cite the standard (file the rule); and (b) any baseline smell you spot: name it and quote the hunk. Distinguish hard violations from judgement calls: documented-standard breaches can be hard, but baseline smells are always judgement calls, and a documented repo standard overrides the baseline. Skip anything tooling enforces. Under 400 words.Spec 子代理 prompt 必须包含diff 命令与提交列表spec 的路径或已获取的内容简报Report: (a) requirements the spec asked for that are missing or partial; (b) behaviour in the diff that wasnt asked for (scope creep); (c) requirements that look implemented but where the implementation looks wrong. Quote the spec line for each finding. Under 400 words.如果 spec 缺失则跳过 Spec 子代理并在最终报告中注明。5. 聚合报告在两个## Standards与## Spec标题下逐字或轻度整理地呈现两份报告。不要合并、不要重排发现。结尾给出一行总结每条轴的发现总数以及每条轴各自的最严重问题如果有。不要在两条轴之间挑单一赢家——那正是这套分离设计要阻止的重排。报告的样子由 SKILL.md 的 Its working if 定义了一组验收标准可用来自检是否跑对遇到坏引用或空 diff 时在派生任何子代理之前拒绝启动报告以## Standards和## Spec两个独立块到达而不是一份合并列表每条 Standards 发现都点名仓库某个文件中的一条规则或十二种 smell 之一并引用对应 hunk每条 Spec 发现都引用 spec 的一行结尾总结给出每条轴的最严重问题且拒绝挑选总体赢家无 spec 可用时Spec 块如实说明而不是列出它从代码推断出的需求。常见问题命名冲突、递归子代理与会话卫生原文档以一组常见问题收尾这些是真实用户报告过的高频坑值得逐一展开。与 Claude Code 内置/code-review的冲突这是该技能被报告最多的一个问题目前没有官方修复。Claude Code 自带一个/code-review做的事情不同它在 diff 里猎 bug而本技能检查 spec 合规与仓库规范。安装本技能库后二者必有一个胜出胜者取决于安装方式通过插件市场plugin marketplace安装一切技能都被冠以mattpocock-skills:前缀内置技能在非限定名下难以触达通过普通 skills 安装本地文件胜出本技能遮蔽内置技能。两个干净的解法其一彻底移除 Claude Code 的内置 skills——这是一个相当大的上下文context节省冲突也随之消失其二把本地副本改名。不过要小心直接改 frontmatter 或重命名目录会被npx skills update撤销。用户报告过的最持久解法是 fork 成新名字、从受管集合中移除code-review并记下 fork 自哪个 commit以便日后手动重新同步。子代理反复调用/code-review导致代理泛滥已知的未关闭 bug多人复现过且发生在不止一个 harness 中。Standards 与 Spec 的 prompt 没有禁止委派因此子代理可能重新发现该技能并再次发散——曾有报告跑到 50 多个代理。社区在 fork 上的修法是在两个子代理简报末尾各加一行“Do not invoke/code-reviewor spawn additional agents: perform this review directly.”。也有人倾向在 harness 层面处理让所有技能都继承这层防护。两者都还没有进入官方技能。如果无人值守运行请盯住代理数量。应该在写代码的同一会话里跑它吗建议开一个新会话。正如一位读者所说“Same context reviewing itself isnt review, its confirmation bias with a slash command.”同一上下文评审自己不是评审而是带斜杠命令的确认偏误。写作会话中的评审 Agent 持有塑造这段代码的全部假设——而这正是独立评审者恰恰不该有的上下文。这也是有人要求implement去掉内置评审步骤的原因它在刚写完 diff 的同一会话里跑评审。从干净会话亲自调用/code-review才是诚实的做法。implement技能的定义implement/SKILL.md确实写明了“Once done, use /code-review to review the work”与“Commit your work to the current branch”印证了这条内置链路。每个 ticket 评审一次还是最后统一评审两种都行技能不替你决定。按 ticket 评审能让每次 diff 足够小Spec 轴有且只有一个明确的 spec 可以对照——这正是implement使用的模式implement → code-review构成构建链的收尾。攒到分支末尾统一评审能抓住 ticket 之间相互作用的问题这是逐 ticket 通过各自漏掉的。拿不准就按 ticket 评审再对分支点做一次最终回归评审。能信任评审结论吗不能不经核对。子代理的输出是假设不是证据曾有一个团队报告散文式评审放过的问题被它抓出十几处破坏性改动。技能把两份报告逐字或轻度整理后聚合而不会针对文件逐一复核每条主张——所以一条发现可能引错位置或夸大影响。在对每条发现行动之前先读它的引用。每条发现都被强制带一个引用一条规范规则、一个 smell 加它的 hunk或一行 spec 行——这正是这份报告可以被核对的原因。为什么每次运行都能发现新问题因为修复会制造新表面积也因为 Standards 轴的判断性那一半在两次运行之间不是确定性的。一位读者如此描述这个循环“/code-review 和 /improve-code-architecture 每次总能发现新东西。我修完、重跑这些技能然后一次又一次。”不存在收敛保证。把一次通过当作一份线索清单对带规则引用的条目行动然后停手。不要循环跑到它变干净为止——它不会。它会评审未提交的工作吗不会。它用三点 difffixed-point...HEAD以 merge-base 为基准排除暂存区与工作区改动。如果implement没有做中间提交即将提交的工作对评审完全不可见。先提交、再评审、然后 amend 或补 fixup。它处于构建链的什么位置code-review是整个构建链尾部tail的评审步骤grill-with-docs → to-spec → to-tickets → implement → code-review同时你也可以把它单独指向任意分支或 PR。这条链上的相邻技能关系如下implement是最接近的邻居它驱动构建并在提交前调用本技能作为收尾评审。其 description 明确声明disable-model-invocation: true即用户显式输入/implement才会触发见 engineering README 对 user-invoked 的说明to-spec与to-tickets产出 Spec 轴要对照的文档一个模糊的 spec 会让那条轴同样模糊。to-spec的模板包含 Problem Statement、Solution、User Stories、Implementation Decisions、Testing Decisions、Out of Scope、Further Notes 七段结构Spec 轴正是拿实现去逐条对这套需求improve-codebase-architecture是“整个代码库”层面的对应物本技能永远只看一个 diffask-matt在整个技能集合上做路由当你不确定该用哪个技能时可以请教它。以 skills/engineering/README.md 中的定位一句话总结这是一个“对固定点以来的 diff 做双轴评审Standards是否遵循仓库规范 Fowler smell 基线与 Spec是否忠实实现来源 issue/spec以并行子代理运行”的工程技能。把两条轴分开报告、把仓库规范当作主要来源、把 smell 当作带修复动作的启发式——这三条设计选择共同保证了评审既能检查代码“写得对不对”又能检查“做的是不是对的事”。【免费下载链接】skillsSkills for Real Engineers. Straight from my .agents directory.项目地址: https://gitcode.com/GitHub_Trending/skills13/skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 code-review 双轴评审：用 Standards 与 Spec 并行子代理检查一次 Git diff
code-review 双轴评审用 Standards 与 Spec 并行子代理检查一次 Git diff【免费下载链接】skillsSkills for Real Engineers. Straight from my .agents directory.项目地址: https://gitcode.com/GitHub_Trending/skills13/skills本指南讲解 GitHub推荐项目精选 / skills13 / skills 仓库中code-review技能的设计与实战用法。它把一次 diff 评审拆成两条互不合并的轴——Standards代码是否按本仓库的编码规范来写与Spec代码是否实现了原始 issue / spec 要求的事——并让两条轴各自在独立的子代理中运行。读完本文你将掌握如何确定评审的固定点fixed point、如何定位 spec 与规范来源、如何解读并行子代理产出的双块报告以及如何在 Claude Code 中规避它与内置/code-review的命名冲突。它做什么对HEAD与固定点之间的 diff 做双轴评审code-review的核心动作是评审HEAD与一个由你指定的固定点之间的 diff。固定点可以是任意 Git 引用一次提交commit、一个分支branch、一个标签tag、main或像HEAD~5这样的相对位置。评审沿着两条互不相干的轴进行轴问题读取的内容报告的内容每条发现引用StandardsIs it built right代码写得对吗仓库文档化的规范 smell 基线文档化的违规可能为硬性与代码坏味道始终是判断规范文件及其规则或具名 smell 加上对应 hunkSpecIs it the right thing做的是正确的事吗发起该工作的 issue 或 spec缺失或部分实现的需求、范围蔓延scope creep、实现错误的需求spec 的对应行两条轴永不合并、永不重排。报告以每条轴各自的最严重问题收尾并拒绝在两条轴之间挑一个“总冠军”。原因是一次改动可能一条轴通过、另一条轴失败——完全遵守仓库约定却实现了错误功能的代码Standards 通过而 Spec 失败精确实现了 ticket 要求却破坏了仓库约定的代码则恰好相反。如果强行合并成一个结论通过的那条轴就会掩盖失败的那条轴。技能仓库中的实际定义skills/engineering/code-review/SKILL.md把这条设计原则写得很清楚A change can pass one axis and fail the other: code that follows every standard but implements the wrong thing → Standards pass, Spec fail. Code that does exactly what the issue asked but breaks the projects conventions → Spec pass, Standards fail. Reporting them separately stops one axis from masking the other.技能在 Claude Code 中通过name: code-review的 frontmatter 与description被模型识别见 SKILL.md 的 frontmatter同时配有最小化的openai.yaml界面声明display_name: Code Review、short_description: Review a diff on standards and spec见 agents/openai.yaml使技能也能在其他兼容 harness 中以统一元数据形式被加载。何时使用它输入/code-review即可调用当用户要求评审一个分支、一个 PR、进行中的工作或任何“自从 X 之后”的改动时Agent 也会自动选择它。技能本身在engineering目录的 README 中被列为“模型可调用”Model-invoked技能与tdd、diagnosing-bugs等并列。原文档给出了一张“按场景选工具”的对照表你的情况应该用存在一个 diff你想知道它是否建得对built right且是正确的事the right thingcode-review你想在 diff 里猎杀 bug空指针路径、竞态、off-by-one用 Claude Code 自带的评审注意下文的命名冲突不是这个技能还没写任何东西想测试先行地写出来tdd一整个 spec 需要被构建含评审环节implement它自己会调用本技能整个代码库都漂移了而不仅仅是某个 diffimprove-codebase-architecture有东西坏了但不知道原因diagnosing-bugs固定点必须由你提供。如果你不提供技能会要求你给出一个而不是自行猜测在派生任何子代理之前它会先确认引用可以被解析git rev-parse fixed-point并且 diff 非空——因此一个打错的分支名会在你面前直接失败而不是在两个子代理内部炸开。这一“先验证后执行”的顺序在 SKILL.md 的 Process 步骤 1 中有完整描述。前置条件两条轴各自的输入要求Standards 轴不需要任何前置配置。它读取仓库中所有文档化了“代码该怎么写”的文件——CODING_STANDARDS.md、CONTRIBUTING.md等——并在仓库没有文档化任何规范时回退到内置的 smell 基线。Spec 轴要求存在一个 spec 并且能被找到。查找顺序如下提交信息中的 issue 引用#123、Closes #45、GitLab 的!67通过docs/agents/issue-tracker.md中的工作流获取你作为参数传入的路径docs/、specs/或.scratch/下与分支名或特性名匹配的 spec 文件直接问你。第 1 步依赖docs/agents/issue-tracker.md该文件由setup-matt-pocock-skills技能写入。如果这个文件缺失只要你手动传入路径Spec 轴依然可用。如果根本没有任何 specSpec 子代理会被跳过报告会明确写“no spec available”而不是凭空编造需求。关于 issue tracker 的实际形态setup-matt-pocock-skills支持 GitHub、GitLab、本地 Markdown 等多种后端见 setup-matt-pocock-skills/SKILL.md。以 GitHub 为例issue-tracker-github.md 规定用gh issue view number --comments获取 ticket 内容、用gh issue list --state open --json number,title,body,labels,comments ...列出 issue并提示 GitHub 中 issue 与 PR 共享编号空间#42可能是任一种需要用gh pr view 42尝试解析后再回退到gh issue view 42。若采用本地 Markdown 后端则按 issue-tracker-local.md 的约定spec 是.scratch/feature-slug/spec.mdticket 是一文件一个 issue。Spec 轴的查找顺序正是顺着这些约定设计的。两条轴的核心规范优先 十二种 Fowler 坏味道基线一个不了解你规范的通用评审技能正是这套设计要避免的东西它会把你代码库里有意的选择当成问题标记出来却漏掉你的代码库真正依赖的不变量。因此Standards 轴把仓库自身的文档当作主要来源primary source并且仓库永远优先the repo always overrides。在仓库规范之下的是smell 基线smell baseline——来自 Martin Fowler《重构》第 3 章的十二种代码坏味道。每条 smell 都是一个“标了标签的启发式”如“possible Feature Envy”永远不是硬性违规每条都以它是什么→怎么修的形式陈述让一条发现附带一个动作而不是一句抱怨。此外任何 linter 已经在强制执行的检查两条轴都会跳过。十二种 smell 完整清单直接取自 SKILL.md 步骤 3Smell识别特征修复方向Mysterious Name神秘命名函数/变量/类型名不能反映其作用或内容重命名若想不出诚实名字说明设计本身不清Duplicated Code重复代码同一逻辑形态出现在改动中的多个 hunk 或文件抽取共享形态两处都调用它Feature Envy依恋情结方法访问另一对象的数据多于自身数据把方法移到它嫉妒的数据上Data Clumps数据泥团同样的几个字段/参数总是一起出现一个待诞生的类型打包成一个类型后整体传递Primitive Obsession基本类型偏执用基本类型或字符串代替值得拥有独立类型的领域概念给概念一个自己的小类型Repeated Switches重复的 switch同一类型上的同一switch/if级联在改动中反复出现用多态替换或两处共享一张映射表Shotgun Surgery霰弹式修改一个逻辑改动被迫散落在 diff 中大量文件里把会一起变化的东西聚成一个模块Divergent Change发散式变化一个文件/模块因多个不相关原因被修改拆分让每个模块只为一个原因变化Speculative Generality夸夸其谈的未来性为 spec 并不需要的需求添加抽象/参数/钩子删掉内联回去直到真实需求出现Message Chains消息链很长的a.b().c().d()导航调用者不该依赖它把遍历藏进第一个对象的一个方法后面Middle Man中间人一个类/函数大部分只是转发砍掉它直接调用真正的目标Refused Bequest被拒绝的遗赠子类/实现者忽略或覆盖了继承来的大部分行为放弃继承改用组合两条绑定规则约束整个基线仓库覆盖基线The repo overrides文档化的仓库规范永远优先当规范认可了基线会标记的东西时抑制该 smell始终是判断Always a judgement call每条 smell 都是带标签的启发式不是硬性违规任何工具已强制的内容都跳过。完整运行流程从固定点到双块报告技能 SKILL.md 的 Process 部分 给出了五步标准流程下面是逐步骤拆解。1. 确定固定点并验证无论用户给出什么固定点commit SHA、分支名、标签、main、HEAD~5都先把它钉住没给就问。随后一次性捕获 diff 命令git diff fixed-point...HEAD # 三点 diff与 merge-base 比较 git log fixed-point..HEAD --oneline三点 diff 是关键git diff fixed-point...HEAD三个点以 merge-base 为基准排除暂存区staged与工作区working-tree的改动。这意味着未提交的工作对评审不可见——必须先 commit、再评审、然后 amend 或补一个 fixup。用两点..的git log列出提交列表则是正确的它给出固定点之后的提交。继续之前先验证git rev-parse fixed-point确认引用可解析且 diff 非空。坏引用或空 diff 应该在这里失败而不是在两个并行子代理内部失败。2. 定位 spec 来源按前文顺序查找提交信息中的 issue 引用 → 用户传入的路径 →docs//specs//.scratch/下匹配分支名的文件 → 问用户。若用户说没有 specSpec 子代理跳过并报告“no spec available”。3. 定位规范来源收集仓库中所有描述“代码该怎么写”的文件CODING_STANDARDS.md、CONTRIBUTING.md等。同时始终携带上一节的十二种 smell 基线无论仓库是否文档化了任何东西。4. 并行派生两个子代理两个子代理并行运行互不污染彼此的上下文。各自 prompt 的构成在 SKILL.md 步骤 4 中有明确规定Standards 子代理 prompt 必须包含完整的 diff 命令与提交列表步骤 3 找到的规范来源文件清单外加完整粘贴的 smell 基线子代理没有其他途径访问它简报Report, per file/hunk where relevant, (a) every place the diff violates a documented standard: cite the standard (file the rule); and (b) any baseline smell you spot: name it and quote the hunk. Distinguish hard violations from judgement calls: documented-standard breaches can be hard, but baseline smells are always judgement calls, and a documented repo standard overrides the baseline. Skip anything tooling enforces. Under 400 words.Spec 子代理 prompt 必须包含diff 命令与提交列表spec 的路径或已获取的内容简报Report: (a) requirements the spec asked for that are missing or partial; (b) behaviour in the diff that wasnt asked for (scope creep); (c) requirements that look implemented but where the implementation looks wrong. Quote the spec line for each finding. Under 400 words.如果 spec 缺失则跳过 Spec 子代理并在最终报告中注明。5. 聚合报告在两个## Standards与## Spec标题下逐字或轻度整理地呈现两份报告。不要合并、不要重排发现。结尾给出一行总结每条轴的发现总数以及每条轴各自的最严重问题如果有。不要在两条轴之间挑单一赢家——那正是这套分离设计要阻止的重排。报告的样子由 SKILL.md 的 Its working if 定义了一组验收标准可用来自检是否跑对遇到坏引用或空 diff 时在派生任何子代理之前拒绝启动报告以## Standards和## Spec两个独立块到达而不是一份合并列表每条 Standards 发现都点名仓库某个文件中的一条规则或十二种 smell 之一并引用对应 hunk每条 Spec 发现都引用 spec 的一行结尾总结给出每条轴的最严重问题且拒绝挑选总体赢家无 spec 可用时Spec 块如实说明而不是列出它从代码推断出的需求。常见问题命名冲突、递归子代理与会话卫生原文档以一组常见问题收尾这些是真实用户报告过的高频坑值得逐一展开。与 Claude Code 内置/code-review的冲突这是该技能被报告最多的一个问题目前没有官方修复。Claude Code 自带一个/code-review做的事情不同它在 diff 里猎 bug而本技能检查 spec 合规与仓库规范。安装本技能库后二者必有一个胜出胜者取决于安装方式通过插件市场plugin marketplace安装一切技能都被冠以mattpocock-skills:前缀内置技能在非限定名下难以触达通过普通 skills 安装本地文件胜出本技能遮蔽内置技能。两个干净的解法其一彻底移除 Claude Code 的内置 skills——这是一个相当大的上下文context节省冲突也随之消失其二把本地副本改名。不过要小心直接改 frontmatter 或重命名目录会被npx skills update撤销。用户报告过的最持久解法是 fork 成新名字、从受管集合中移除code-review并记下 fork 自哪个 commit以便日后手动重新同步。子代理反复调用/code-review导致代理泛滥已知的未关闭 bug多人复现过且发生在不止一个 harness 中。Standards 与 Spec 的 prompt 没有禁止委派因此子代理可能重新发现该技能并再次发散——曾有报告跑到 50 多个代理。社区在 fork 上的修法是在两个子代理简报末尾各加一行“Do not invoke/code-reviewor spawn additional agents: perform this review directly.”。也有人倾向在 harness 层面处理让所有技能都继承这层防护。两者都还没有进入官方技能。如果无人值守运行请盯住代理数量。应该在写代码的同一会话里跑它吗建议开一个新会话。正如一位读者所说“Same context reviewing itself isnt review, its confirmation bias with a slash command.”同一上下文评审自己不是评审而是带斜杠命令的确认偏误。写作会话中的评审 Agent 持有塑造这段代码的全部假设——而这正是独立评审者恰恰不该有的上下文。这也是有人要求implement去掉内置评审步骤的原因它在刚写完 diff 的同一会话里跑评审。从干净会话亲自调用/code-review才是诚实的做法。implement技能的定义implement/SKILL.md确实写明了“Once done, use /code-review to review the work”与“Commit your work to the current branch”印证了这条内置链路。每个 ticket 评审一次还是最后统一评审两种都行技能不替你决定。按 ticket 评审能让每次 diff 足够小Spec 轴有且只有一个明确的 spec 可以对照——这正是implement使用的模式implement → code-review构成构建链的收尾。攒到分支末尾统一评审能抓住 ticket 之间相互作用的问题这是逐 ticket 通过各自漏掉的。拿不准就按 ticket 评审再对分支点做一次最终回归评审。能信任评审结论吗不能不经核对。子代理的输出是假设不是证据曾有一个团队报告散文式评审放过的问题被它抓出十几处破坏性改动。技能把两份报告逐字或轻度整理后聚合而不会针对文件逐一复核每条主张——所以一条发现可能引错位置或夸大影响。在对每条发现行动之前先读它的引用。每条发现都被强制带一个引用一条规范规则、一个 smell 加它的 hunk或一行 spec 行——这正是这份报告可以被核对的原因。为什么每次运行都能发现新问题因为修复会制造新表面积也因为 Standards 轴的判断性那一半在两次运行之间不是确定性的。一位读者如此描述这个循环“/code-review 和 /improve-code-architecture 每次总能发现新东西。我修完、重跑这些技能然后一次又一次。”不存在收敛保证。把一次通过当作一份线索清单对带规则引用的条目行动然后停手。不要循环跑到它变干净为止——它不会。它会评审未提交的工作吗不会。它用三点 difffixed-point...HEAD以 merge-base 为基准排除暂存区与工作区改动。如果implement没有做中间提交即将提交的工作对评审完全不可见。先提交、再评审、然后 amend 或补 fixup。它处于构建链的什么位置code-review是整个构建链尾部tail的评审步骤grill-with-docs → to-spec → to-tickets → implement → code-review同时你也可以把它单独指向任意分支或 PR。这条链上的相邻技能关系如下implement是最接近的邻居它驱动构建并在提交前调用本技能作为收尾评审。其 description 明确声明disable-model-invocation: true即用户显式输入/implement才会触发见 engineering README 对 user-invoked 的说明to-spec与to-tickets产出 Spec 轴要对照的文档一个模糊的 spec 会让那条轴同样模糊。to-spec的模板包含 Problem Statement、Solution、User Stories、Implementation Decisions、Testing Decisions、Out of Scope、Further Notes 七段结构Spec 轴正是拿实现去逐条对这套需求improve-codebase-architecture是“整个代码库”层面的对应物本技能永远只看一个 diffask-matt在整个技能集合上做路由当你不确定该用哪个技能时可以请教它。以 skills/engineering/README.md 中的定位一句话总结这是一个“对固定点以来的 diff 做双轴评审Standards是否遵循仓库规范 Fowler smell 基线与 Spec是否忠实实现来源 issue/spec以并行子代理运行”的工程技能。把两条轴分开报告、把仓库规范当作主要来源、把 smell 当作带修复动作的启发式——这三条设计选择共同保证了评审既能检查代码“写得对不对”又能检查“做的是不是对的事”。【免费下载链接】skillsSkills for Real Engineers. Straight from my .agents directory.项目地址: https://gitcode.com/GitHub_Trending/skills13/skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考