skill-code-review

宿主：Codex CLI — 此技能专为 Claude Code 设计，并已适配 Codex。 交叉引用命令在 Codex 中使用已安装的技能名称，而不是 /octo:* 斜杠命令。 使用当前已启用的 Codex shell 和子 Agent 工具。在当前会话未提供相关能力之前，不要声称某个提供方、模型或宿主子 Agent 可用。 有关宿主工具的对应项，请参阅 skills/blocks/codex-host-adapter.md。

代码审查技能

必须遵守 — 不得跳过

调用此技能时，必须执行多 LLM 审查流程。禁止：

• 不经过多提供方综合分析，直接进行单模型代码审查
• 擅自认定范围“过于宽泛”并缩小范围，而不询问用户
• 跳过提供方检查或结构化审查阶段
• 用两个后台 Sonnet Agent 取代完整的多提供方流程
• 为“聚焦审计会更有效”寻找借口——用户希望获得多 LLM 视角

你的第一行输出必须是： 🐙 **CLAUDE OCTOPUS ACTIVATED** - Multi-LLM Code Review

在 ink（交付）阶段调用 code-reviewer persona，进行全面的代码分析。

快速模式

进行快速健全性检查（已暂存的更改、小型 PR）时，跳过完整审查流程，只运行两个阶段：

# Quick: grasp (consensus on scope) → tangle (parallel review)
${HOME}/.claude-octopus/plugin/scripts/orchestrate.sh grasp "[review request]"
${HOME}/.claude-octopus/plugin/scripts/orchestrate.sh tangle "[synthesized scope]"

当用户说“检查这个 PR”“快速审查”“帮我检查更改是否合理”或进行提交前检查时，使用快速模式。对于涉及安全或架构影响的 PR，使用完整审查。

用法

# Via orchestrate.sh
${HOME}/.claude-octopus/plugin/scripts/orchestrate.sh spawn code-reviewer "Review this pull request for security issues"

# Via auto-routing (detects review intent)
${HOME}/.claude-octopus/plugin/scripts/orchestrate.sh auto "review the authentication implementation"

功能

• AI 驱动的代码质量分析
• 安全漏洞检测
• 性能优化建议
• 架构与设计模式审查
• TDD 合规性与测试优先证据审查
• 自主代码生成风险检测
• 最佳实践执行

Persona 参考

此技能封装了以下位置定义的 code-reviewer persona：

• agents/personas/code-reviewer.md
• CLI：codex-review
• 模型：gpt-5.2-codex
• 阶段：ink

示例提示词

"Review this PR for OWASP Top 10 vulnerabilities"
"Analyze the error handling in src/api/"
"Check for memory leaks in the connection pool"
"Review the test coverage for the auth module"

自主实现审查

当审查上下文显示 AI-assisted、Autonomous / Dark Factory 或来源不明时，应提高审查严格度。不要仅仅因为生成的代码看起来完善，就认为它值得信任。

TDD 证据

检查是否有具体迹象表明更改遵循了红—绿—重构流程，而不是先实现再补测试：

• 如有条件，比较差异和近期历史，确认测试是否在生产代码更改之前或同时添加。
• 优先选择定义行为的测试，而不是仅复述实现的快照测试或大量依赖 mock 的测试。
• 确认生产代码只包含满足测试所需的最少内容，而不是带有未使用选项的推测性抽象。
• 如果缺少证据，将 TDD 合规性标记为未知，不要假定已采用 TDD。

自主代码生成风险模式

发现高自主性输出中常见的模式时，应提高问题等级或新增问题：

• 测试或当前需求无法证明合理性的选项繁多的 API 或抽象
• 占位逻辑、由 TODO/FIXME 驱动的控制流，或看似“为未来准备”的死分支
• mock、fake 或 dummy 行为泄漏到生产路径
• 未接入的组件、未使用的辅助函数，或没有执行路径的代码
• 静默错误处理、宽泛的 catch 块、缺少日志或运维可见性不足
• 对高风险更改缺少回滚说明、迁移防护或发布安全检查

审查输出附加内容

当自主性或 TDD 属于审查范围时，在审查综合结果中添加一个简短部分：

## TDD / Autonomy Assessment

- Provenance: Human-authored | AI-assisted | Autonomous / Dark Factory | Unknown
- TDD evidence: Confirmed | Partial | Unknown
- Autonomous risk signals: None | Minor | Significant
- Recommendation: Ship | Fix before merge | Re-run with /octo:tdd or tighter supervision

实现完整性验证

code-reviewer persona 完成后，运行存根检测，以验证实现完整性。

存根检测流程

步骤 1：获取已更改文件

# Get files changed in the commit/PR
if [ -n "$COMMIT_RANGE" ]; then
    changed_files=$(git diff --name-only "$COMMIT_RANGE")
else
    changed_files=$(git diff --name-only HEAD~1..HEAD)
fi

# Filter for source code files
source_files=$(echo "$changed_files" | grep -E "\.(ts|tsx|js|jsx|py|go)$")

步骤 2：检查存根模式

检查每个已更改文件，查找常见的存根标记：

for file in $source_files; do
    echo "Checking $file for stubs..."

    # Check 1: Comment-based stubs
    stub_count=$(grep -E "(TODO|FIXME|PLACEHOLDER|XXX)" "$file" 2>/dev/null | wc -l | tr -d ' ')

    if [ "$stub_count" -gt 0 ]; then
        echo "⚠️  WARNING: Found $stub_count stub indicators in $file"
        grep -n -E "(TODO|FIXME|PLACEHOLDER)" "$file" | head -3
    fi

    # Check 2: Empty function bodies
    empty_functions=$(grep -E "function.*\{\s*\}|const.*=>.*\{\s*\}" "$file" 2>/dev/null | wc -l | tr -d ' ')

    if [ "$empty_functions" -gt 0 ]; then
        echo "❌ ERROR: Found $empty_functions empty functions in $file"
        echo "   Empty functions must be implemented before merge"
    fi

    # Check 3: Return null/undefined
    null_returns=$(grep -E "return (null|undefined);" "$file" 2>/dev/null | wc -l | tr -d ' ')

    if [ "$null_returns" -gt 0 ]; then
        echo "⚠️  WARNING: Found $null_returns null/undefined returns in $file"
        echo "   Verify these are intentional, not stubs"
    fi

    # Check 4: Substantive content check
    substantive_lines=$(grep -vE "^\s*(//|/\*|\*|import|export|$)" "$file" 2>/dev/null | wc -l | tr -d ' ')

    if [[ "$file" == *.tsx ]] && [ "$substantive_lines" -lt 10 ]; then
        echo "⚠️  WARNING: Component $file only has $substantive_lines substantive lines"
        echo "   Components should typically be >10 lines"
    fi

    # Check 5: Mock/test data in production
    mock_data=$(grep -E "const.*(mock|test|dummy|fake).*=" "$file" 2>/dev/null | wc -l | tr -d ' ')

    if [ "$mock_data" -gt 0 ]; then
        echo "⚠️  WARNING: Found $mock_data references to mock/test data in $file"
        echo "   Ensure these are not placeholders for production code"
    fi
done

步骤 3：将结果添加到审查综合结果

在审查输出中包含存根检测结果：

## Implementation Completeness

**Stub Detection Results:**

✅ **Fully Implemented Files:**
- src/components/UserProfile.tsx (42 substantive lines)
- src/api/users.ts (67 substantive lines)

⚠️  **Files with Warnings:**
- src/components/Dashboard.tsx
  - 3 TODO comments (non-blocking)
  - Consider addressing before release

❌ **Files Requiring Implementation:**
- src/utils/analytics.ts
  - 2 empty functions detected (BLOCKING)
  - Must implement before merge

**Verification Levels:**
- Level 1 (Exists): 5/5 files ✅
- Level 2 (Substantive): 3/5 files ⚠️
- Level 3 (Wired): 4/5 files ✅
- Level 4 (Functional): Tests pending

**Recommendation:**
- Fix empty functions in analytics.ts before merge
- Address TODO comments in Dashboard.tsx in follow-up PR
- All other files meet implementation standards

存根检测参考

请参阅 .claude/references/stub-detection.md，了解全面的模式和检测策略。

何时阻止合并

阻止合并的问题（必须修复）：

• ❌ 函数体为空
• ❌ 在生产代码路径中使用模拟数据
• ❌ 组件未在任何地方导入或接入
• ❌ API 端点返回空对象

不阻止合并的问题（在评审中注明）：

• ⚠️ TODO/FIXME 注释（创建后续任务）
• ⚠️ 返回 null（如果是有意为之）
• ⚠️ 行数较少（如果适合该组件）

将评审发布到 PR（v8.44.0）

生成评审综合结果后，检查当前分支是否有未关闭的 PR，并询问是否要将发现作为 PR 评论发布。

第 1 步：检测未关闭的 PR

# Check if we're on a branch with an open PR
CURRENT_BRANCH=$(git rev-parse --abbrev-ref HEAD 2>/dev/null || echo "")
PR_NUM=""

if [[ -n "$CURRENT_BRANCH" && "$CURRENT_BRANCH" != "main" && "$CURRENT_BRANCH" != "master" ]]; then
    if command -v gh &>/dev/null; then
        PR_NUM=$(gh pr list --head "$CURRENT_BRANCH" --json number --jq '.[0].number' 2>/dev/null || echo "")
    fi
fi

第 2 步：发布评审评论

如果存在未关闭的 PR，将评审发现作为 PR 评论发布：

if [[ -n "$PR_NUM" ]]; then
    echo "Found open PR #${PR_NUM} on branch ${CURRENT_BRANCH}"

    # Build the review comment body from synthesis
    REVIEW_BODY="## Code Review — Claude Octopus

${REVIEW_SYNTHESIS}

*Review generated by Claude Octopus (/octo:review)*
*Providers: available external providers + 🔵 Claude*"

    # Post through the outbound credential gate. Never interpolate generated
    # Markdown directly into a gh shell argument.
    REPO_SLUG=$(gh repo view --json nameWithOwner --jq .nameWithOwner)
    if ! "${CLAUDE_PLUGIN_ROOT:-${HOME}/.claude-octopus/plugin}/scripts/safe-gh-comment.sh" \
            --repo "$REPO_SLUG" pr-comment "$PR_NUM" - <<< "$REVIEW_BODY"; then
        echo "GitHub write state is unknown; check for the review comment before retrying:" >&2
        gh pr view "$PR_NUM" --repo "$REPO_SLUG" --comments || true
        return 1 2>/dev/null || exit 1
    fi
    echo "Review posted to PR #${PR_NUM}"

    # Update agent registry if this agent is tracked
    REGISTRY="${HOME}/.claude-octopus/plugin/scripts/agent-registry.sh"
    if [[ -x "$REGISTRY" ]]; then
        AGENT_ID=$(git rev-parse --abbrev-ref HEAD 2>/dev/null || echo "")
        "$REGISTRY" update "$AGENT_ID" --pr "$PR_NUM" 2>/dev/null || true
    fi
fi

**如果不存在 PR：**跳过发布，仅在终端中展示评审。 **如果 gh CLI 不可用：**跳过发布，并建议用户安装 GitHub CLI。

何时自动发布，何时先询问

• **自动发布：**作为 /octo:deliver、/octo:factory 或 /octo:embrace 的一部分调用时（自动化工作流）
• **先询问：**通过 /octo:review 单独调用时——使用 AskUserQuestion：

  "PR #N found. Post review findings as a PR comment?"
  Options: "Yes, post to PR", "No, terminal only"