skill-code-review

ホスト: Codex CLI — このスキルは Claude Code 向けに設計され、Codex 向けに適応されています。 相互参照コマンドは、Codex では /octo:* スラッシュコマンドではなく、インストール済みのスキル名を使用します。 アクティブな Codex シェルとサブエージェントツールを使用してください。現在のセッションが公開するまで、プロバイダー、モデル、またはホストのサブエージェントが利用可能であると主張しないでください。 ホストツールの対応物については、skills/blocks/codex-host-adapter.md を参照してください。

コードレビュースキル

必須遵守 — 省略しないでください

このスキルが呼び出された場合、マルチ LLM レビューパイプラインを実行しなければなりません。以下は禁止されています:

• マルチプロバイダーの統合を行わずに、単一モデルで直接コードレビューを行うこと
• スコープが「広すぎる」と判断し、ユーザーに確認せずに狭めること
• プロバイダーチェックまたは構造化されたレビューフェーズを省略すること
• 完全なマルチプロバイダーパイプラインの代わりに、2 つのバックグラウンド Sonnet エージェントで代用すること
• 「焦点を絞った監査のほうが効果的だろう」と正当化すること — ユーザーはマルチ LLM の視点を求めています

最初の出力行は必ず次のとおりにしてください: 🐙 **CLAUDE OCTOPUS ACTIVATED** - Multi-LLM Code Review

ink（デリバリー）フェーズにおいて、徹底的なコード分析のために code-reviewer ペルソナを呼び出します。

クイックモード

迅速な健全性チェック（ステージングされた変更、小さな PR）では、完全なレビューパイプラインを省略し、2 つのフェーズだけを実行します:

# 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 遵守とテストファーストの証跡レビュー
• 自律的なコード生成リスクの検出
• ベストプラクティスの徹底

ペルソナ参照

このスキルは、以下で定義された code-reviewer ペルソナをラップします:

• 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 の証跡

その変更がテスト後実装ではなく、レッド・グリーン・リファクタリングに従ったことを示す具体的な兆候を確認します:

• 利用可能な場合は差分と最近の履歴を比較し、テストが本番コードの変更より前に追加されたか、同時に追加されたかを確認します。
• 実装をただ言い換えるだけのスナップショットのみのテストやモック多用のテストよりも、振る舞いを定義するテストを優先します。
• 本番コードが、未使用のオプションを備えた投機的な抽象化ではなく、テストを満たすために必要な最小限に見えるかを検証します。
• 証跡が欠けている場合は、TDD 遵守を不明としてマークし、TDD が行われたと仮定しないでください。

自律的コード生成のリスクパターン

高い自律性を持つ出力に一般的なパターンが見られる場合、所見を格上げするか追加します:

• テストや現在の要件によって正当化されていない、オプション過多の API や抽象化
• プレースホルダーロジック、TODO/FIXME 主導の制御フロー、または「将来対応」に見えるデッドブランチ
• モック、フェイク、ダミーの動作が本番パスに漏れ出している
• 配線されていないコンポーネント、未使用のヘルパー、または実行パスなしで存在するコード
• サイレントな失敗処理、広範な 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 ペルソナが完了した後、スタブ検出を実行して実装の完全性を検証します。

スタブ検出プロセス

ステップ 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"