Code Quality Reviewer Prompt Template-北京尧图网络

Code Quality Reviewer Prompt Template【免费下载链接】superpowersAn agentic skills framework software development methodology that works.项目地址: https://gitcode.com/GitHub_Trending/su/superpowersUse this template when dispatching a code quality reviewer subagent.Purpose:Verify one tasks implementation is well-built (clean, tested, maintainable)Only dispatch after spec compliance review passes.Subagent (general-purpose): description: Review code quality for Task N prompt: | You are reviewing one tasks implementation for code quality. This is a task-scoped gate, not a merge review — a broad whole-branch review happens separately after all tasks are complete. ## What Was Implemented [DESCRIPTION] ## Task Requirements (context only) [TASK_TEXT] ## Git Range to Review **Base:** [BASE_SHA] **Head:** [HEAD_SHA] bash git diff --stat [BASE_SHA]..[HEAD_SHA] git diff [BASE_SHA]..[HEAD_SHA] ## Read-Only Review Your review is read-only on this checkout. Do not mutate the working tree, the index, HEAD, or branch state in any way. Use tools like git show, git diff, and git log to inspect history. ## Scope Spec compliance was already verified by a separate reviewer. Do not re-check whether the code matches the requirements or the plan. Start from the diff. Read the changed files first. Inspect code outside the diff only to evaluate a concrete risk you can name — and name it in your report. Cross-cutting changes are legitimate named risks: if the diff changes lock ordering, a function or API contract, or shared mutable state, checking the call sites is the right method. Do not crawl the codebase by default. ## Tests The implementer already ran the tests and reported results with TDD evidence for exactly this code. Do not re-run the suite to confirm their report. Run a test only when reading the code raises a specific doubt that no existing run answers — and then a focused test, never a package-wide suite, race detector run, or repeated/high-count loop. If heavy validation seems warranted, recommend it in your report instead of running it. If you cannot run commands in this environment, name the test you would run. ## What to Check **Code quality:** - Clean separation of concerns? - Proper error handling? - DRY without premature abstraction? - Edge cases handled? **Tests:** - Do the new and changed tests verify real behavior, not mocks? - Are the tasks edge cases covered? **Structure:** - Does each file have one clear responsibility with a well-defined interface? - Are units decomposed so they can be understood and tested independently? - Is the implementation following the file structure from the plan? - Did this change create new files that are already large, or significantly grow existing files? (Dont flag pre-existing file sizes — focus on what this change contributed.) ## Calibration Categorize issues by actual severity. Not everything is Critical. Acknowledge what was done well before listing issues — accurate praise helps the implementer trust the rest of the feedback. ## Output Format ### Strengths [Whats well done? Be specific.] ### Issues #### Critical (Must Fix) [Bugs, data loss risks, broken functionality] #### Important (Should Fix) [Poor error handling, test gaps, structural problems] #### Minor (Nice to Have) [Code style, optimization opportunities] For each issue: - File:line reference - Whats wrong - Why it matters - How to fix (if not obvious) ### Assessment **Task quality:** [Approved | Needs fixes] **Reasoning:** [1-2 sentence technical assessment]Placeholders:[DESCRIPTION]— task summary, from implementers report[TASK_TEXT]— the tasks requirements text or plan reference, for context[BASE_SHA]— commit before this task[HEAD_SHA]— current commitReviewer returns:Strengths, Issues (Critical/Important/Minor), Task quality verdict相对旧模板这里保留了代码质量、测试质量、结构与可维护性维度丢掉了 plan alignment、安全/扩展/生产就绪维度与合并判定判定词从 Ready to merge? 换成 Task quality: Approved | Needs fixes。Scope 与 Tests 两节是范围预算与测试预算的正文——注意那句 If you cannot run commands in this environment, name the test you would run这是为没有命令执行权限的只读评审 harness 预留的通道设计文档提到 Antigravity 将评审模板映射到 research 类型无命令权限。 **验证grep 即验收** bash grep -c requesting-code-review skills/subagent-driven-development/code-quality-reviewer-prompt.md || echo ABSENT # 期望ABSENT不再委托 grep -n Task quality: skills/subagent-driven-development/code-quality-reviewer-prompt.md | head -2 # 期望恰好一处Output Format 的判定行Reviewer returns 页脚写作 Task quality verdict无冒号 grep -n worktree add\|Ready to merge skills/subagent-driven-development/code-quality-reviewer-prompt.md || echo CLEAN # 期望CLEAN 通过后提交 bash git add skills/subagent-driven-development/code-quality-reviewer-prompt.md git commit -m Make per-task quality reviewer prompt self-contained and task-scoped ## Task 2规格评审提示词的四处精确编辑对象是 skills/subagent-driven-development/spec-reviewer-prompt.md计划中的行号以 commit f55642e 时的文件为准。四处编辑各自对应一个根因 **编辑 1加入 judge from the diff 条款。** 在 Only read files in this diff. Do not crawl the broader codebase. 之后插入 Spec compliance is judged by reading the diff against the requirements. The implementer already ran the tests and reported TDD evidence — do not re-run them. If a requirement cannot be verified from this diff alone (it lives in unchanged code or spans tasks), report it as a ⚠️ item instead of broadening your search. **编辑 2裁剪只读章节。** 把含 git worktree add /tmp/review-[SHA] 操作说明的长句替换为 Your review is read-only on this checkout. Do not mutate the working tree, the index, HEAD, or branch state in any way. Use tools like git show, git diff, and git log to inspect history. 理由设计文档diff 范围内的评审永远不需要检出另一个修订。 **编辑 3让怀疑有依据。** 把 The implementer finished suspiciously quickly. Their report may be incomplete, inaccurate, or optimistic. You MUST verify everything independently. 替换为 Treat the implementers report as unverified claims about the code. It may be incomplete, inaccurate, or optimistic. Verify the claims against the diff. 同等的不信任但不再虚构一个事实完成得快得可疑是未经证实的断言。 **编辑 4增加第三判定通道 ⚠️。** 把 Report: - ✅ Spec compliant (if everything matches after code inspection) - ❌ Issues found: [list specifically whats missing or extra, with file:line references] 替换为 Report: - ✅ Spec compliant (if everything matches after code inspection) - ❌ Issues found: [list specifically whats missing or extra, with file:line references] - ⚠️ Cannot verify from diff: [requirements you could not verify from the diff alone, and what the controller should check — report alongside the ✅/❌ verdict for everything you could verify] ⚠️ 通道解决了一个流程矛盾流程图里的二元通过/失败菱形无法路由无法从 diff 验证的项所以既不扩大搜索、也不静默放行而是显式上报给控制器控制器处理规则见 Task 4。 **验证与提交** bash grep -n suspiciously\|worktree add skills/subagent-driven-development/spec-reviewer-prompt.md || echo CLEAN # 期望CLEAN grep -c ⚠️ skills/subagent-driven-development/spec-reviewer-prompt.md # 期望2judge-from-diff 条款判定通道各一处 git add skills/subagent-driven-development/spec-reviewer-prompt.md git commit -m Spec reviewer: judge from the diff, grounded skepticism, ⚠️ verdict channel ## Task 3实现者提示词——修复评审发现后必须重跑测试评审者不要重跑实现者的测试这条规则有一个隐含前提实现者每次修复后都会重跑测试。Task 3 把前提变成现实。在 skills/subagent-driven-development/implementer-prompt.md 的 ## Report Format 一行之前插入新章节 ## After Review Findings If a reviewer finds issues and you fix them, re-run the tests that cover the amended code and include the results in your fix report. Reviewers will not re-run tests for you — your report is the test evidence. **验证与提交** bash grep -n After Review Findings skills/subagent-driven-development/implementer-prompt.md # 期望一处匹配位于 ## Report Format 之前 git add skills/subagent-driven-development/implementer-prompt.md git commit -m Implementer prompt: re-run covering tests after fixing review findings ## Task 4SKILL.md 的六处控制器修改这是改动量最大的一步六处编辑让控制器controller获得怎么写评审提示词、怎么处置 ⚠️ 项、终评走哪个模板的显式规则。行号同样以 commit f55642e 为准。 **编辑 1终评流程图节点指向宽模板。** 节点标签 Dispatch final code reviewer subagent for entire implementation 出现 3 次当时在第 65、84、85 行3 处全部替换为 Dispatch final code reviewer subagent (../requesting-code-review/code-reviewer.md) 计划文档特别提醒**Graphviz 节点按标签文本匹配——三处必须逐字节一致否则图会多出一个幽灵节点**。 **编辑 2评审模型选择从最强大改为判断。** 把 **Architecture, design, and review tasks**: use the most capable available model. **Task complexity signals:** 替换为 **Architecture and design tasks**: use the most capable available model. **Review tasks**: choose the model with the same judgment, scaled to the diffs size, complexity, and risk. A small mechanical diff does not need the most capable model; a subtle concurrency change does. **Task complexity signals (implementation tasks):** 即窄 diff 评审不再自动映射到最宽代码库理解 → 最强模型。 **编辑 3在 ## Prompt Templates 之前插入两个控制器指导章节** ## Handling Spec Reviewer ⚠️ Items The spec reviewer may report ⚠️ Cannot verify from diff items — requirements that live in unchanged code or span tasks. These do not block dispatching the code quality reviewer, but you must resolve each one yourself before marking the task complete: you hold the plan and cross-task context the reviewer lacks. If you confirm an item is a real gap, treat it as a failed spec review — send it back to the implementer and re-review. ## Constructing Reviewer Prompts Per-task reviews are task-scoped gates. The broad review happens once, at the final whole-branch review. When you fill a reviewer template: - Do not add open-ended directives like check all uses or run race tests if useful without a concrete, task-specific reason - Do not ask a reviewer to re-run tests the implementer already ran on the same code — the implementers report carries the test evidence ⚠️ 项不阻塞派发动质量评审但控制器必须在标记任务完成前逐条自行解决——因为它掌握评审者缺乏的计划与跨任务上下文确认为真实缺口的按规格评审失败退回实现者。 **编辑 4模板列表加终评指针。** 把 - code-quality-reviewer-prompt.md - Dispatch code quality reviewer subagent 替换为 - code-quality-reviewer-prompt.md - Dispatch code quality reviewer subagent - Final whole-branch review: use superpowers:requesting-code-reviews [code-reviewer.md](https://link.gitcode.com/i/47d9d46cd60fe8418e8fc61b7fd8d841) 这一步防止孤儿化移除每任务质量提示词对 code-reviewer.md 的委托后若不显式指路最终评审模板就再没有引用入口。 **编辑 5示例工作流改用新判定词。** 两处替换 Code reviewer: Strengths: Good test coverage, clean. Issues: None. Approved. 改为 Code reviewer: Strengths: Good test coverage, clean. Issues: None. Task quality: Approved. Code reviewer: ✅ Approved 改为 Code reviewer: ✅ Task quality: Approved 终评者的 ready to merge 一行当时在第 199 行保持不变。 **编辑 6Integration 章节措辞收窄。** 把 - **superpowers:requesting-code-review** - Code review template for reviewer subagents 改为 - **superpowers:requesting-code-review** - Code review template for the final whole-branch review **验证四条 grep与提交** bash grep -c Dispatch final code reviewer subagent (../requesting-code-review/code-reviewer.md) skills/subagent-driven-development/SKILL.md # 期望3 grep -n most capable available model skills/subagent-driven-development/SKILL.md # 期望恰好一处architecture/design 条目 grep -n Handling Spec Reviewer\|Constructing Reviewer Prompts skills/subagent-driven-development/SKILL.md # 期望两个章节标题均位于 ## Prompt Templates 之前 grep -c Task quality: Approved skills/subagent-driven-development/SKILL.md # 期望2 git add skills/subagent-driven-development/SKILL.md git commit -m SDD controller: reviewer prompt budgets, ⚠️ handling, final-review pointer, model judgment ## Task 5新评测场景——植入一个只有任务级质量评审能抓住的缺陷该场景放在 evals/ **子模块**中独立仓库 superpowers-evals在子模块里开分支开发父仓库的 submodule 指针在收尾时统一提升。场景设计非常精巧 - 脚手架生成一个很小的 Node 项目两任务的计划formatUserReport 与 formatAdminReport。 - 计划的 Task 2 实现代码**逐字复制** Task 1 的 banner 格式化逻辑.repeat(40) 等。 - 这种重复是**规格合规的**需求只描述行为所以规格评审应当放行它——被测的门正是每任务代码质量评审抓 DRY 违规。 **新增/修改的文件** - 新建 evals/setup_helpers/sdd_quality_defect_plan.py - 修改 evals/setup_helpers/__init__.py注册新脚手架 - 新建 evals/scenarios/sdd-quality-reviewer-catches-planted-defect/ 下的 story.md、setup.sh、checks.sh **Step 0子模块开分支** bash cd evals git checkout -b sdd-quality-defect-scenario **Step 1Python 脚手架助手。** 核心是一个两任务计划文本 PLAN_BODYTask 1 定义 formatUserReportTask 2 定义Same banner layout的 formatAdminReport实现片段逐字重复与 scaffold_sdd_quality_defect_plan(workdir) 函数在 workdir 里 git init -b main、写入 package.json含 test: node --test、把 PLAN_BODY 写到 docs/superpowers/plans/report-plan.md然后 git add -A 提交 initial: report formatter plan。计划中两个任务的实现片段即被植入的重复逻辑形如 javascript export function formatUserReport(user) { const banner .repeat(40); const lines []; lines.push(banner); lines.push(Report for ${user.name} ${user.email}); lines.push(banner); lines.push(Visits: ${user.visits}); lines.push(banner); return lines.join(\n); } 计划文档特别提醒Python 源码中必须写成 \\n这样生成的 Markdown 里是字面 \nJS 读起来才是 lines.join(\n)。 **Step 2注册助手。** 在 evals/setup_helpers/__init__.py 的 scaffold_sdd_yagni_plan 导入行之后加 from setup_helpers.sdd_quality_defect_plan import scaffold_sdd_quality_defect_plan并在注册表中 scaffold_sdd_yagni_plan: scaffold_sdd_yagni_plan, 之后加 scaffold_sdd_quality_defect_plan: scaffold_sdd_quality_defect_plan,。 **Step 3story.md节选 frontmatter 与验收标准** markdown --- id: sdd-quality-reviewer-catches-planted-defect title: SDDs per-task code quality review catches a planted DRY violation status: ready tags: subagent-driven-development quorum_max_time: 90m --- 正文告诉评测操作员计划里 Task 2 的实现片段逐字复制 Task 1 的格式化逻辑重复是规格合规的规格评审应当放行**被测的门是每任务代码质量评审**让 agent 用 superpowers:subagent-driven-development 技能端到端执行计划若它问成品放哪回答合并回 main 检出若质量评审标记了重复逻辑、实现者重构了它让评审-修复循环完整演出来——这个循环正是被测行为。 markdown ## Acceptance Criteria - A Skill invocation naming superpowers:subagent-driven-development and at least one Agent (subagent dispatch) tool call appear in the session log. - The duplicated report-formatting logic did not survive to the end of the run. Either (a) the implementer never introduced the duplication (wrote or self-reviewed its way to shared logic), or (b) the per-task code quality reviewer flagged the duplication as an issue and a review-fix loop removed it. A fail looks like the duplicated logic shipping with the per-task quality reviewer approving it, or the duplication being caught only by the final whole-branch review. - The per-task quality reviewers stayed task-scoped: no package-wide test suites, race detector runs, or repeated/high-count test loops appear in reviewer subagent activity, and reviewers did not re-run the full test suite merely to confirm the implementers report. - npm test passes in the main checkout and both formatUserReport and formatAdminReport are exported from src/report.js. 注意第二条的fail定义重复逻辑被**放行**质量评审通过、或**只被最终整分支评审抓到**都算失败——它精确锁死了任务级质量评审是抓住缺陷的机制这一断言。第三条则直接对任务级评审保持任务级范围无包级测试、无 race 检测、无重复跑套件做了会话日志层面的断言。 **Step 4setup.sh** bash #!/usr/bin/env bash set -euo pipefail uv run setup-helpers run scaffold_sdd_quality_defect_plan 记得 chmod x。 **Step 5checks.sh无执行位** bash pre() { git-repo git-branch main requires-tool npm file-exists docs/superpowers/plans/report-plan.md file-contains docs/superpowers/plans/report-plan.md formatAdminReport file-contains docs/superpowers/plans/report-plan.md repeat$40$ } post() { skill-called superpowers:subagent-driven-development tool-called Agent command-succeeds npm test file-contains src/report.js export function formatUserReport file-contains src/report.js export function formatAdminReport command-succeeds test $(grep -c repeat(40) src/report.js) -le 1 } 最后一条是**确定性的 DRY 门**banner 构造 .repeat(40) 在最终文件里至多出现一次——共享而非逐函数复制。 **Step 6-7子模块内验证并提交** bash cd evals uv run quorum check # 期望通过新场景列在列表中 uv run ruff check uv run pytest -x -q git add setup_helpers/sdd_quality_defect_plan.py setup_helpers/__init__.py scenarios/sdd-quality-reviewer-catches-planted-defect/ git commit -m Add sdd-quality-reviewer-catches-planted-defect scenario ## Task 6静态验证扫查不改文件只做三条扫查 bash # 1. 父仓库无悬空引用 grep -rn requesting-code-review skills/subagent-driven-development/ # 期望匹配只出现在 SKILL.md终评流程图节点 ×3、Prompt Templates 指针、Integration 条目 # code-quality-reviewer-prompt.md 中没有任何匹配 grep -rn Ready to merge skills/subagent-driven-development/ || echo CLEAN # 期望CLEAN # 2. 插件基础设施测试 bash tests/shell-lint/test-lint-shell.sh # 期望全部 PASS新增 setup.sh 只在 evals 子模块里有自己的检查 # 3. 跨平台工具表仍自洽 grep -n code-quality-reviewer skills/using-superpowers/references/antigravity-tools.md skills/using-superpowers/references/gemini-tools.md # 期望两张表仍把 code-quality-reviewer 列为评审模板 # 新提示词里 If you cannot run commands ... name the test you would run # 保持了只读 research 映射的有效性无需改表 ## Task 7Live before/after 评测维护者门槛 live quorum 运行会以宽松模式启动 agent CLI是**受信维护者操作**按计划由维护者 Jesse 执行且需要 ANTHROPIC_API_KEY。 **基线改动前的技能** bash cd evals export SUPERPOWERS_ROOT主检出路径未含本分支改动的 checkout uv run quorum run scenarios/sdd-rejects-extra-features --coding-agent claude uv run quorum run scenarios/sdd-go-fractals --coding-agent claude uv run quorum run scenarios/sdd-svelte-todo --coding-agent claude uv run quorum run scenarios/spec-reviewer-catches-planted-flaws --coding-agent claude【免费下载链接】superpowersAn agentic skills framework software development methodology that works.项目地址: https://gitcode.com/GitHub_Trending/su/superpowers创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

Code Quality Reviewer Prompt Template

相关推荐

Vector 数据管道指南：从日志采集到集中汇聚，一条配置就够的完整教程

国产SPI NOR Flash替代实战：SM25QH128与JFM25F32A选型与驱动要点

深度学习入门实战：从环境配置到CNN模型构建的完整指南

更多资讯

工地太忙根本没时间复习考试？电工证考试科目3技巧+上岗必备全攻略

云南电工证培训天数不够用，工地太忙根本没时间复习考试怎么办？

电工证包括家电维修吗？考前押题全攻略来了

电工证办理办理通过率揭秘：学历不高怕报不上名？真实情况全在这

珠海考电工证的地方怎么转证？官方报名入口在这儿

电工证过期时间你知道吗？内部消息告诉你怎么转异地

今日更新

金坛办电工证在哪里？考前押题能帮你少走弯路

怎样查看真假电工证怎么考

史密斯内部电工证值不值得考？怕考不过白交培训费的看过来

本周精选

安监局电工证分数查询怎么查才能知道含金量高不高

新疆电工作业干活累吗良心建议助你避开考不过的坑

中牟县电工证怎么报名外省证能转吗

本月热门

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

读完文章，想聊聊您的网站？