name: harness-review description: “多角度审查代码、计划和范围。品质守护者，为您服务。当用户提到审查、代码审查、计划审查、范围分析、安全性、性能、质量检查、PRs、差异或变更审查时使用。不要用于：实施工作、新功能开发、bug修复或设置。” description-en: “代码、计划和范围的多角度审查。品质守护者为您服务。当用户提到审查、代码审查、计划审查、范围分析、安全性、性能、质量检查、PRs、差异或变更审查时使用。不要用于：实施工作、新功能开发、bug修复或设置。” description-ja: “多角度审查代码、计划和范围。品质守护者，为您服务。当用户提到审查、代码审查、计划审查、范围分析、安全性、性能、质量检查、PRs、差异或变更审查时使用。不要用于：实施工作、新功能开发、bug修复或设置。” allowed-tools: [“Read”, “Grep”, “Glob”, “Bash”, “Task”] context: fork argument-hint: “[code|plan|scope]” hooks:
- event: PreToolCall type: command command: “${CLAUDE_PLUGIN_ROOT}/scripts/check-codex.sh” once: true
审查技能
负责代码审查、计划审查和范围分析的技能群。 从上下文自动判定审查类型。
审查类型（上下文感知）
审查类型从上下文自动判定：
| Recent Activity | Review Type | 4 Experts |
|---|---|---|
/plan-with-agent 后 |
计划审查 | 清晰度、可行性、依赖性、接受度 |
/work 后 |
代码审查 | 安全性、性能、质量、可访问性 |
| 任务添加后 | 范围审查 | 范围蔓延、优先级、可行性、影响 |
手动指定
/harness-review # 自动判定
/harness-review code # 强制代码审查
/harness-review plan # 强制计划审查
/harness-review scope # 强制范围分析
功能详情（代码审查）
| 功能 | 详情 |
|---|---|
| 变更审查 | 参见 references/changes-review.md |
| 质量检查 | 参见 references/quality-review.md |
| 安全性 | 参见 references/security-review.md |
| 性能 | 参见 references/performance-review.md |
| 可访问性 | 参见 references/accessibility-review.md |
| SEO/OGP | 参见 references/seo-review.md |
| Codex 集成 | 参见 references/codex-integration.md |
| 提交判定 | 参见 references/commit-judgment-logic.md |
功能详情（计划/范围审查）
计划审查和范围审查使用 Codex 专家：
| 审查类型 | 专家 | 参考 |
|---|---|---|
| 计划审查 | 清晰度、可行性、依赖性、接受度 | ../codex-review/references/experts/clarity-expert.md 等 |
| 范围审查 | 范围蔓延、优先级、可行性、影响 | ../codex-review/references/experts/scope-creep-expert.md 等 |
详情: …/codex-review/references/codex-parallel-review.md
执行步骤
- 质量判定门（步骤0）
- 剩余上下文确认（Codex 模式时）（步骤1）
- 用户的请求分类
- （Claude-mem 有效时）搜索过去的审查指摘
- 并行执行的判定（下记参照）
- 从上述的“功能详情”中读取适当的参考文件，或启动并行子代理
- 整合结果完成审查
输入的优先顺序
- 如果传递了
files，则 仅以该文件 为对象进行审查 - 如果没有传递
files，则从git_diff推定变更处 - 如果传递了
context_from: code_content，则 优先以该内容 进行审查
Step 0: 质量判定门（审查重点领域的特定）
审查开始前分析变更内容，特定重点领域：
变更文件分析
↓
┌─────────────────────────────────────────┐
│ 质量判定门 │
├─────────────────────────────────────────┤
│ 判定项目: │
│ ├── 覆盖率不足？（测试なし） │
│ ├── 安全性注意？（auth/api/） │
│ ├── a11y 注意？（UI 组件） │
│ └── 性能注意？（DB/循环） │
└─────────────────────────────────────────┘
↓
决定重点审查领域
覆盖率判定
| 状况 | 指摘内容 |
|---|---|
| 新文件无测试 | “测试不足” |
| 变更文件的测试旧 | “考虑更新测试” |
| 覆盖率 < 60% | “推荐提高覆盖率” |
安全性重点审查
| 路径 | 追加检查项目 |
|---|---|
| auth/, api/ | OWASP Top 10 检查清单 |
| 输入处理 | 净化、验证 |
| DB 查询 | 参数化确认 |
a11y 重点审查
| 路径 | 检查项目 |
|---|---|
| src/components/ | alt, aria, 键盘操作 |
| src/pages/ | 标题结构, 焦点管理 |
性能重点审查
| 模式 | 警告内容 |
|---|---|
| 循环内 DB 查询 | N+1 查询的可能性 |
| 大规模数据处理 | 考虑分页 |
| useEffect 滥用 | 渲染优化 |
SEO/OGP 重点审查
| 路径 | 检查项目 |
|---|---|
| src/pages/, app/ | title, description, canonical |
| public/ | robots.txt, sitemap.xml, OGP 图片 |
| layout.tsx, _document.tsx | viewport, OGP 标签, Twitter Card |
跨平台重点审查
| 路径 | 检查项目 |
|---|---|
| src/components/, app/ | 响应式（固定宽检查） |
| *.css, *.scss, tailwind | 100vw 使用、overflow 设定 |
| public/ | favicon, apple-touch-icon |
重点审查整合输出
📊 质量判定结果 → 重点审查领域
| 判定 | 该当 | 对象文件 |
|------|------|-------------|
| 安全性 | ⚠️ | src/api/auth.ts |
| 覆盖率 | ⚠️ | src/utils/helpers.ts (测试なし) |
| a11y | ✅ | - |
| 性能 | ✅ | - |
| SEO/OGP | ⚠️ | app/layout.tsx (OGP 未设定) |
| 跨平台 | ✅ | - |
→ 重点审查安全性・覆盖率・SEO
LSP 基础的影响分析（推荐）
变更审查时使用 LSP 工具确认影响范围：
| 变更类型 | LSP 操作 | 确认内容 |
|---|---|---|
| 函数签名变更 | findReferences | 全调用源是否对应 |
| 类型定义变更 | findReferences | 使用处的类型兼容性 |
| API 变更 | incomingCalls | 受影响的端点 |
审查流程:
- 特定变更文件
- 使用
LSP.findReferences列举影响范围 - 包含受影响文件进行审查
使用例:
# 1. 确认变更函数的参照处
LSP operation=findReferences filePath="src/api/user.ts" line=42 character=15
# 2. 确认函数的调用层次
LSP operation=incomingCalls filePath="src/api/user.ts" line=42 character=15
# 3. 确认类型定义的使用处
LSP operation=findReferences filePath="src/types/api.ts" line=10 character=12
输出例:
🔍 LSP 影响分析结果
变更: updateUserProfile() 的签名变更
受影响处:
├── src/pages/profile.tsx:89 ⚠️ 参数更新必要
├── src/pages/settings.tsx:145 ⚠️ 参数更新必要
├── tests/user.test.ts:67 ✅ 更新済
└── src/api/admin.ts:23 ⚠️ 参数更新必要
→ 3处需要参数更新
注: 仅在使用 LSP 服务器的语言中动作。
Step 1: 剩余上下文确认（Codex 模式时）
Codex 模式（review.mode: codex）时，如果剩余上下文低于30%，则先执行 /compact。
注意: /compact 后如果余裕少，不减退继续执行。
Git log 扩展标志的活用（CC 2.1.49+）
审查时的提交分析活用结构化日志。
变更履历的结构化分析
# 结构化格式获取提交履历
git log --format="%h|%s|%an|%ad" --date=short -10
# 排除合并提交进行审查
git log --cherry-pick --no-merges main..HEAD
# 附带变更文件一覧
git log --raw -5
主要活用场面
| 用途 | 标志 | 效果 |
|---|---|---|
| 提交一覧获取 | `–format="%h | %s"` |
| 审查对象的明确化 | --cherry-pick --no-merges |
排除合并提交 |
| 变更影响分析 | --raw |
文件变更的详细显示 |
| 时间序列的原因追踪 | --topo-order |
拓扑排序 |
输出例
📊 提交履历分析（结构化）
| Hash | Subject | Author | Date |
|------|---------|--------|------|
| a1b2c3d | feat: add auth | Alice | 2026-02-04 |
| e4f5g6h | fix: cors error | Bob | 2026-02-03 |
变更文件（--raw）:
├── src/auth.ts (Modified)
├── src/api/middleware.ts (Added)
└── tests/auth.test.ts (Modified)
→ 重点审查认证周围的变更
Step 2: 过去的审查指摘搜索（Memory-Enhanced）
Claude-mem 有效时，审查开始前搜索过去的类似指摘：
# mem-search 搜索过去的审查指摘
mem-search: type:review "{变更文件的模式}"
mem-search: concepts:security "{安全性相关的关键词}"
mem-search: concepts:gotcha "{变更处相关的关键词}"
表示例:
📚 过去的审查指摘（相关）
| 日期 | 指摘内容 | 文件 |
|------|---------|---------|
| 2024-01-15 | XSS脆弱性: innerHTML 使用禁止 | src/components/*.tsx |
| 2024-01-20 | N+1查询: prefetch 必须 | src/api/*.ts |
💡 本次审查重点检查上述模式
注: Claude-mem 未设定时，此步骤跳过。
审查模式的选择
审查技能以2种模式动作：
设定确认: .claude-code-harness.config.yaml
↓
├── review.mode: default → Claude 单体审查
└── review.mode: codex → Codex 并行审查（审查类型毎4专家）
Default 模式（Claude 单体）
Claude 直接执行审查。适合小〜中规模变更。
Codex 模式（并行专家）
通过 Codex MCP 根据审查类型相应的4个专家 个别并行调用:
| Review Type | 专家 |
|---|---|
| 代码审查 | 安全性、性能、质量、可访问性 |
| 计划审查 | 清晰度、可行性、依赖性、接受度 |
| 范围审查 | 范围蔓延、优先级、可行性、影响 |
⚠️ Codex 模式执行时的必须规则
绝对不要1次的 MCP 调用中まとめ多个专家。
✅ 正确: 4次的 MCP 调用在1个响应内并行执行
❌ 错误: 1次调用中请求“全观点审查”
执行步骤:
- 判定调用的专家（全部ではなく必要なもののみ）:
- 设定中
enabled: false→ 除外 - CLI/后端 → 可访问性, SEO 除外
- 仅文档变更 → 优先质量、架构师、计划审查者、范围分析师（安全性、性能可除外）
- 设定中
- 从有效专家的
experts/*.md个别读取 提示 - 仅有效专家 在 Bash 后台进程中并行执行
codex exec - 整合各结果进行判定
详情: codex-review/references/codex-parallel-review.md
Codex 模式有效化:
/codex-mode on
详情: references/codex-integration.md
并行子代理启动（Default 模式）
变更文件数・审查观点的算出（必须）
files_count 以 merge-base 基准算出（包括 staged/unstaged）:
base=$(git merge-base HEAD origin/main 2>/dev/null \
|| git merge-base HEAD main 2>/dev/null \
|| git merge-base HEAD master 2>/dev/null \
|| git rev-parse HEAD~1 2>/dev/null \
|| git hash-object -t tree /dev/null)
committed=$(git diff --name-only --diff-filter=ACMRTUXB $base...HEAD)
staged=$(git diff --name-only --cached)
unstaged=$(git diff --name-only)
files=$(echo -e "$committed
$staged
$unstaged" | sort -u | grep -v '^$')
files_count=$(echo "$files" | wc -l)
review_aspects 以路径基础检测:
function countReviewAspects(files) {
let aspects = 0;
if (files.some(f => /\/(auth|api|middleware|security)\//.test(f))) aspects++;
if (files.some(f => /\/(db|sql|repository|cache)\//.test(f))) aspects++;
if (files.some(f => /\/(components|pages|app)\/.*\.tsx$/.test(f))) aspects++;
if (files.some(f => /\/(pages|app)\/.*\.(metadata|head|seo)/.test(f))) aspects++;
return Math.max(aspects, 1);
}
满足以下条件両方时，使用 Task tool 并行启动 code-reviewer:
- 审查观点 >= 2（例: 安全性 + 性能）
- 变更文件 >= 5
启动模式（1个响应内同时调用多个 Task tool）:
Task tool 并行调用:
#1: subagent_type="code-reviewer"
prompt="安全性观点审查: {files}"
#2: subagent_type="code-reviewer"
prompt="性能观点审查: {files}"
#3: subagent_type="code-reviewer"
prompt="代码质量观点审查: {files}"
小规模时（不满足条件）:
- 顺序读取子技能（doc.md）并直列执行
🔧 MCP Code Intelligence 工具的活用
审查中活用 MCP 工具（AST-Grep, LSP）提高精度。
重要:
/dev-tools-setup中设定 MCP 服务器时，优先使用 MCP 工具 而非标准工具（Grep, Read）。MCP 工具可以进行结构性搜索，获得更准确结果。
AST-Grep MCP 工具（harness_ast_search）
用于结构性的代码模式搜索。比基于正则表达的 Grep 精度高，适合代码臭味检测。
| 检测模式 | AST-Grep 模式 | 用途 |
|---|---|---|
| Debug logs | console.log($$$) |
发布前残留日志检测 |
| Empty catch | catch ($ERR) { } |
错误握りつぶし检测 |
| Unused async | async function $NAME($$$) { $BODY } |
无 await async 检测 |
| Magic numbers | 数值文字搜索 | 硬编码常数检测 |
使用例:
harness_ast_search pattern="console.log($$$)" language="typescript" path="src/"
harness_ast_search pattern="catch ($ERR) { }" language="typescript" path="src/"
输出例:
🔍 AST-Grep Code Smell Scan
Patterns checked:
- console.log($$$) → Debug logs
- catch ($ERR) { } → Empty catch blocks
Results:
├── 3x console.log found (src/api/*.ts)
├── 1x empty catch block (src/utils/error.ts:45)
└── 0x unused async
注:
harness_ast_search不可用时，フォールバック到sg命令（Bash）或 Grep。
🔧 LSP 功能的活用
审查中活用 LSP（Language Server Protocol）提高精度。
MCP 版优先:
harness_lsp_*MCP 工具可用时，优先使用标准 LSP 工具。
LSP 整合到审查
| 审查观点 | LSP 活用方法 |
|---|---|
| 质量 | Diagnostics 自动检测型错误・未使用变量 |
| 安全性 | Find-references 追踪机密数据的流 |
| 性能 | Go-to-definition 确认重处理的实现 |
LSP Diagnostics 的输出例
📊 LSP 诊断结果
| 文件 | 错误 | 警告 |
|---------|--------|------|
| src/components/Form.tsx | 0 | 2 |
| src/utils/api.ts | 1 | 0 |
⚠️ 检测到1件错误
→ 添加到审查指摘事项
Find-references 的影响分析
🔍 变更影响分析
变更: validateInput()
参照处:
├── src/pages/signup.tsx:34
├── src/pages/settings.tsx:56
└── tests/validate.test.ts:12
→ 测试覆盖済 ✅
🔧 PDF 页面范围读取（Claude Code 2.1.49+）
文档审查时高效处理大型 PDF 的功能。
页面范围指定读取
// 页面范围指定读取
Read({ file_path: "docs/architecture.pdf", pages: "1-15" })
// 仅变更履历セクション
Read({ file_path: "docs/changelog.pdf", pages: "5-12" })
// 仅安全性要件
Read({ file_path: "docs/requirements.pdf", pages: "45-60" })
文档审查时的推荐方法
| 审查对象 | 推荐读取方法 | 理由 |
|---|---|---|
| 大型仕様书 | 目录 + 仅变更处 | 集中相关セクション |
| API设计书 | 端点一覧 + 安全性章 | 优先重要观点 |
| 架构文档 | 系统构成図 + 非机能要件 | 絞り込み审查对象 |
| 用户手册 | 目录 + 可访问性项 | 确认易用性 |
| 发布ノート | 仅最新版本的变更点 | 特定相关变更 |
审查观点别的活用例
安全性审查
大型安全性仕様书（200ページ）的审查:
1. **目录把握结构**（1-3ページ）
Read({ file_path: "security-spec.pdf", pages: "1-3" })
2. **精读认证・认可章**（25-45ページ）
Read({ file_path: "security-spec.pdf", pages: "25-45" })
3. **精读脆弱性対策章**（78-92ページ）
Read({ file_path: "security-spec.pdf", pages: "78-92" })
此方法，仅安全性审查必要な部分効率確認。
性能审查
性能要件书（150ページ）的审查:
1. **目录和摘要**（1-5ページ）
Read({ file_path: "performance-spec.pdf", pages: "1-5" })
2. **响应时间要件**（34-50ページ）
Read({ file_path: "performance-spec.pdf", pages: "34-50" })
3. **负荷测试结果**（120-135ページ）
Read({ file_path: "performance-spec.pdf", pages: "120-135" })
审查工作流整合
Step 0: 质量判定门（文档分析）
文档审查时，首先页面范围指定把握概要:
1. 读目录理解结构
Read({ file_path: "spec.pdf", pages: "1-3" })
2. 特定变更处
从目录获取变更セクション的页面号
3. 仅精读相关セクション
Read({ file_path: "spec.pdf", pages: "{变更范围}" })
4视点审查时的活用
| 观点 | 应读页面范围 | 例 |
|---|---|---|
| 安全性 | 认证・认可、暗号化、脆弱性対策 | pages: “25-45,78-92” |
| 性能 | 非机能要件、负荷测试结果 | pages: “34-50,120-135” |
| 质量 | 编码规约、测试戦略 | pages: “60-75” |
| 可访问性 | UI/UX要件、WCAG准拠 | pages: “95-110” |
ベストプラクティス
| 原则 | 说明 |
|---|---|
| 目录优先 | 常先目录把握结构后详细 |
| 观点别页面范围 | 审查观点毎特定必要页面 |
| 集中变更差分 | 既存文档仅审查变更处 |
| 重要度顺 | Critical → Major → Minor 顺序读 |
トークン消费的比较
| 审查方法 | 文档规模 | トークン消费 | 审查精度 |
|---|---|---|---|
| 全页面读取 | 200ページ | ~100,000 | 高 |
| 页面范围指定 | 必要30ページ | ~15,000 | 高 |
→ 可能85%的トークン削減和审查时间短縮
注意事项
- 页面范围1-indexed（1ページ目是
pages: "1"） - 未支持多范围（将来扩展対応予定）
- 现时点仅可指定连续页面范围
VibeCoder 向
📝 请求代码检查时的说法
1. **“检查一下”**
- 整体看有没有问题
2. **“安全性没问题？”**
- 检查是否能抵抗恶意攻击
3. **“不慢吗？”**
- 检查速度没问题
4. **“谁都能用？”**
- 检查残障人士也能使用
💡 提示: 说“全部检查一下”的话，
自动确认4个观点全部