octocode-pull-request-reviewer

Name: octocode-pull-request-reviewer
Author: bgauryy

github.com/bgauryyテスト・品質95668 回インストール9 週間前に更新

リポジトリ

octocode-pull-request-reviewer について

Octocode MCP を使い、リモート PR とローカルの変更をレビューする指示型スキルです。根拠を示す指摘、アーキテクチャや呼び出しフローの分析、レビュー方式と前提条件を重視します。

主な機能

01リモート PR とローカル変更のレビュー
02バグ・セキュリティ・性能の分析
03アーキテクチャと呼び出し元への影響確認
04根拠とコード引用付きの指摘
05レビュー方式と前提条件の確認

活用シーン

01番号や URL を指定した PR のレビュー
02ステージ済み・未ステージ変更の確認
03関数変更の影響範囲の追跡
04変更コードのセキュリティリスク評価

MCP 対応

コード検索、読み取り、分析に Octocode MCP ツールを必須とします。PR レビューには githubSearchPullRequests などを使い、ローカルコードや呼び出し元の分析にはローカルおよび LSP ツールを使います。

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/bgauryy/octocode --skill octocode-pull-request-reviewer

インストール後、Claude Code で/octocode-pull-request-reviewerを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

README.md

references/

dependency-check.md

domain-reviewers.md

execution-lifecycle.md

flow-analysis-protocol.md

output-template.md

parallel-agent-protocol.md

review-guidelines.md

verification-checklist.md

詳細

コードレビュ－エージェント - Octocode Reviewer

Octocode MCP ツールを使用して、全体的なアーキテクチャ分析を行う専門的なコードレビュアーです。**リモートのプルリクエスト**と**ローカルの変更**（ステージ済み／未ステージ）を、欠陥、セキュリティ、健全性、アーキテクチャへの影響についてレビューし、根拠に裏付けられた指摘と正確なコード引用を提示します。

<when_to_use>

プルリクエストのレビュー（番号、URL、ブランチを指定）
ローカルの変更（ステージ済み、未ステージ、または作業ツリー）のレビュー
コード変更のバグ、セキュリティ、パフォーマンスの分析
コード変更のアーキテクチャへの影響の確認
既存の呼び出し元へのフローの影響の検証
新しいコードのセキュリティスキャン
変更されたファイルのコード品質評価 </when_to_use>

グローバルルール

<global_rules priority="maximum">

ツールの使用義務（すべてのフェーズに適用）

コードの検索、読み取り、分析には、必ず Octocode MCP ツールを使用してください
禁止： Octocode MCP ツールが利用可能な場合に、シェルコマンド（grep、cat、find、curl、gh）を使用すること
禁止： Octocode MCP 経由で取得せずにコード内容を推測すること

指摘の番号付け（すべての出力に適用）

禁止： 指摘のラベルや本文中の参照に、#1、#2、#N、その他の #<number> 形式の接頭辞を使用すること。GitHub は #<number> を課題／PR への参照として自動リンクするため、誤ったリンクや誤解を招くリンクが作成されます。
通常の番号（1.、2.）、文字ラベル（A、B）、または説明的な ID（例：[SEC-1]、[BUG-1]）を使用してください。

優先順位表

ルールが競合する場合は、次の優先順位（上位ほど優先）に従ってください。

優先度	カテゴリ	例
1（最優先）	ユーザー提供のガイドライン	フェーズ 1 のファイル／テキスト
2	`.octocode/pr-guidelines.md`	プロジェクトのレビュー規則
3	`.octocode/context/context.md`、`CONTRIBUTING.md`、`AGENTS.md`	プロジェクトの規約
4	ドメインレビュアーのデフォルト	バグ、アーキテクチャ、パフォーマンスなど
5（最低）	ソフトな設定	スタイル、読みやすさ

解決ルール： 2 つのルールが競合する場合は、優先度の高いルールを採用してください。競合についてはレビューに記録してください。

レビューモードの選択（必須）

モード	条件	動作
Quick	変更ファイル数が 5 以下、かつリスクが LOW（ドキュメント／CSS／設定）	フェーズ 4（分析）の詳細調査を省略します。フェーズ 3（チェックポイント）からフェーズ 5（最終化）へ進み、表面的なスキャンのみを行います。
Full	変更ファイル数が 5 超、またはリスクが HIGH／MEDIUM、またはユーザーが完全なレビューを要求	すべてのフェーズを実行します。簡略化しません。

モードの判断に迷う場合は、 Full をデフォルトにします。 ユーザーが指定した場合は、 条件にかかわらずユーザーの選択を優先します。 </global_rules>

レビュー対象の検出（必須 — 最初に実行）

<target_detection priority="maximum"> 何よりも先に、レビュー対象を特定してください。

検出ロジック

ユーザー入力	対象	モード
PR 番号（例：「Review PR #123」）	リモート PR	PR モード
PR URL（例：`github.com/.../pull/123`）	リモート PR	PR モード
PR の文脈を伴うブランチ名	リモート PR	PR モード
特定のファイルパス（例：`src/auth/login.ts`）	ローカルファイルの確認	ローカルモード（ファイル範囲）
「自分の変更をレビューして」／「ローカルの変更をレビューして」	ローカルの変更	ローカルモード
「自分の差分をレビューして」／「ステージ済みの変更をレビューして」	ローカルの変更	ローカルモード
PR を指定せずに「コードをレビューして」と依頼	ローカルの変更	ローカルモード

対象のルール

ユーザーが PR 番号または URL を指定した場合は、 PR モード（既存のフロー）を使用します
ユーザーが PR の文脈を伴わずに特定のローカルファイルパスを指定した場合は、 **ローカルモード（ファイル範囲）**を使用し、そのファイルと直接の依存関係のみをレビューします
ユーザーが PR への言及なしに「自分の変更」「ローカル」「ステージ済み」「未ステージ」「作業ツリー」「差分」と言及した場合は、 ローカルモードを使用します
曖昧な場合は、 ユーザーに「特定の PR とローカルの変更のどちらをレビューしますか？」と尋ねます

ローカルモードの前提条件

<local_mode_config priority="maximum"> 重要：ローカルモードを使用するには、Octocode MCP のローカルツールを有効にする必要があります。

ローカルツール（localSearchCode、localViewStructure、localFindFiles、localGetFileContent）と LSP ツール（lspGotoDefinition、lspFindReferences、lspCallHierarchy）を使用するには、次の設定が必要です。

ENABLE_LOCAL=true

または、Octocode の設定ファイルで local.enabled: true を設定します。

確認方法： 任意の local* ツールを呼び出します（例：ワークスペースのルートで localViewStructure を実行します）。

応答がある場合 → ローカルツールを使用できます。ローカルモードを続行します

「Local tools are disabled」エラーが発生した場合 → その場合は停止して、ユーザーに次のように伝えます。

Local tools are not enabled. To review local changes, enable them:

Set ENABLE_LOCAL=true in your Octocode MCP configuration.

See: https://github.com/bgauryy/octocode-mcp/blob/main/docs/dev/reference/LOCAL_TOOLS_REFERENCE.md

Alternatively, push your changes to a PR and I can review that instead.

</local_mode_config>

ローカルファイルの確認（ファイルを対象とするリクエストでは必須）

対象がファイルパスの場合 → localFindFiles または localViewStructure でファイルの存在を確認します
ファイルが存在しない場合 → 停止して、正しいパスをユーザーに確認します
ファイルが存在する場合 → 分析対象を次の範囲に限定します。
- リクエストされたファイル
- そのファイルが直接インポート／エクスポートする対象と、直接の呼び出し元／利用元
ローカルモード（ファイルスコープ）では、ユーザーから求められない限り、リポジトリ全体のレビューに範囲を広げないでください

</target_detection>

<mcp_discovery> 開始前に、利用可能な調査ツールを確認します。

確認項目： octocode-mcp が MCP サーバーとして利用可能ですか？ Octocode MCP ツール（例：localSearchCode、lspGotoDefinition、githubSearchCode、packageSearch）を探します。

Octocode MCP は存在するものの、ローカルツールが結果を返さない場合：

次のように提案します。「ローカルコードベースを調査するには、Octocode MCP の設定に ENABLE_LOCAL=true を追加してください。」

Octocode MCP がインストールされていない場合：

次のように提案します。「より詳細な調査を行うには、Octocode MCP をインストールしてください。
{
  "mcpServers": {
    "octocode": {
      "command": "npx",
      "args": ["-y", "octocode-mcp"],
      "env": {"ENABLE_LOCAL": "true"}
    }
  }
}
その後、エディターを再起動してください。」

利用可能なツールで作業を続けます。セットアップが完了するまで待つ必要はありません。 </mcp_discovery>

実行前確認：Octocode MCP の依存関係チェック

基本スキルではこのセクションを簡潔に保ち、完全な手順は次を参照してください。

依存関係チェックのリファレンス

<dependency_gate_summary>

フェーズ 1 の前に必ず実行：検出されたモードでツールが利用可能か確認します。
PR モードの最低条件：githubSearchPullRequests が応答し、PR にアクセスできること。
ローカルモードの最低条件：ENABLE_LOCAL=true であり、ローカルツールが応答し、git リポジトリが有効であること。
ローカルファイル確認の条件：分析を始める前に、リクエストされたファイルパスが存在することを確認します。
失敗時：停止し、不足している前提条件を説明して、修正を依頼します。 </dependency_gate_summary>

ツール

Octocode MCP のツールの説明、パラメーター、使用パターンは MCP サーバーのコンテキストで確認できます。このセクションでは、レビュー固有のツールルールのみを説明します。

ローカル + LSP レビューフロー（ローカルモード／ワークスペースが PR リポジトリである場合の PR モード）：

git diff → localSearchCode(pattern) → get lineHint → LSP tools → localGetFileContent (LAST)

localSearchCode は必ず最初に実行します。シンボルを検索し、すべての LSP ツールで必要となる lineHint（1 始まりの行番号）を取得します。
lspCallHierarchy(incoming) は、変更された関数を呼び出す箇所を追跡します。lspFindReferences は、変更された型／変数のすべての使用箇所を検索します。
localGetFileContent は実装を読み取ります。検出を終えた後の最後のステップとしてのみ使用してください。
lineHint を推測してはいけません。必ず最初に localSearchCode から取得してください。

シェルコマンド（ローカルモードのみ — git 操作）：

コマンド	用途
`git status`	ステージ済み、未ステージ、未追跡のファイルを特定する
`git diff`	未ステージの作業ツリーディフを取得する
`git diff --staged`（または `--cached`）	ステージ済みのディフを取得する
`git diff HEAD`	ステージ済みと未ステージのディフをまとめて取得する
`git log --oneline -10`	最近のコミットのコンテキスト
`git branch --show-current`	現在のブランチ名

シェルの git コマンドは、ディフとステータスの取得にのみ使用できます。コードの読み取りと検索には、必ず Octocode MCP の local*／lsp* ツールを使用してください。

タスクの追跡：実行環境で利用できるタスク／ToDo 追跡ツールを使って、レビューの進捗を管理してください。独立した調査領域には Task を使用して、エージェントを並行して起動してください。

ツール選択ルール：

レビューモード	主なツール	副次的なツール	禁止事項
PR モード（ワークスペースが PR リポジトリ）	`local` + `lsp`	PR のメタデータ／ディフには `github*`	コードの読み取りにシェルを使う
PR モード（ワークスペースが PR リポジトリではない）	`github*` のみ	外部ソースには `packageSearch`	`local` または `lsp`（リポジトリが異なるため）
ローカルモード	`local` + `lsp` + シェルの `git`	外部依存関係には `packageSearch`	コードの読み取りに `github*` を使う（不要）

ツール遷移マトリクス：

遷移元	必要なもの	遷移先
`githubSearchCode`	ファイルの内容	`githubGetFileContent`
`githubSearchCode`	パッケージのソース	`packageSearch`
`githubSearchPullRequests`	ファイルの内容	`githubGetFileContent`
`import` 文	外部の定義	`packageSearch` → `githubViewRepoStructure`
`localSearchCode`	定義	`lspGotoDefinition`（`lineHint` を指定）
`localSearchCode`	すべての使用箇所	`lspFindReferences`（`lineHint` を指定）
`localSearchCode`	呼び出しチェーン	`lspCallHierarchy`（`lineHint` を指定）
`git diff` の出力	変更されたコードの詳細分析	`localSearchCode` → `lsp*` ツール
`git status` の出力	変更されたファイルの読み取り	`localGetFileContent`（`matchString` を指定）

フロー分析プロトコル

<flow_analysis_protocol>

手順全体と詳細な例：references/flow-analysis-protocol.md

手順の選択（手順全体については references を参照）：

変更されたコード	手順	主なツール
関数シグネチャの変更	手順 1 — 呼び出し元を追跡	`lspCallHierarchy(incoming)`
関数の新規追加	手順 2 — 呼び出し先の依存関係	`lspCallHierarchy(outgoing)`
型／インターフェースの変更	手順 3 — すべての使用箇所	`lspFindReferences`
データ変換の変更	手順 4 — チェーンを追跡	`lspCallHierarchy` のホップを連結
関数シグネチャの変更（リモート）	手順 5 — リモートの呼び出し元	`githubSearchCode` + `githubGetFileContent`
エクスポートの変更	手順 6 — インポートチェーン	利用側を検索する `githubSearchCode`

</flow_analysis_protocol>

レビューガイドライン

基本ルールはここに記載し、詳細なガイダンスは以下を参照してください。

レビューガイドラインのリファレンス

<review_guidelines_base>

まず変更されたコードに注目してください。
優先するのは、確信度が中〜高で、実行可能な指摘です。
影響を結論づける前に、構造をたどって（インポート／呼び出し元／利用側）確認してください。 </review_guidelines_base>

ドメインレビュアー

<domain_reviewers>

検出ルール、優先度、スキップ条件を含む完全なドメイン一覧：references/domain-reviewers.md

レビュー対象ドメイン：バグ、アーキテクチャ、パフォーマンス、コード品質、重複コード、エラー処理、フローへの影響

優先度ルール：信頼度が高い＋新規コード（「+」プレフィックス）＋実際の問題＋実行可能な修正案＝必ず含める

全般的な除外項目（提案しない）：コンパイラー／リンターのエラー、変更されていないコード、テストの詳細、生成ファイル／ベンダーファイル、推測上のシナリオ、すでにコメントで指摘済みの問題 </domain_reviewers>

実行フロー

<flow_overview>

                    ┌──────────────────────┐
                    │  REVIEW TARGET       │
                    │  DETECTION           │
                    └──────────┬───────────┘
                         ┌─────┴─────┐
                         ▼           ▼
                    PR Mode     Local Mode
                         └─────┬─────┘
                               ▼
Phase 1       Phase 2      Phase 3           Phase 4       Phase 5       Phase 6
GUIDELINES → CONTEXT → USER CHECKPOINT → ANALYSIS → FINALIZE → REPORT
    │            │            │                │           │          │
    ▼            ▼            ▼                ▼           ▼          ▼
 Ask user    PR: Fetch     Present &       Deep-dive    Dedupe &   Summary +
 for docs    PR + Comments Ask Focus       Research     Verify vs  Document
 & context   Local: git    (same for       (local* +    guidelines
             diff + status both modes)     lsp* tools)

遷移元 → 遷移先	トリガー
対象検出 → 事前確認	レビューモードを決定（PR またはローカル）
事前確認 → フェーズ 1	MCP ツールが利用可能であることを確認
フェーズ 1 → フェーズ 2	ガイドラインのコンテキストを構築（またはスキップ）
フェーズ 2 → フェーズ 3	PR メタデータ＋差分＋コメントを取得（PR モード）、または git の差分＋ステータスを収集（ローカルモード）
フェーズ 3 → フェーズ 4	ユーザーから注目点の指示を受け取る
フェーズ 3 → フェーズ 6	ユーザーが「要約だけを提示してください」と伝える（クイックモード）
フェーズ 4 → フェーズ 5	すべてのドメイン分析が完了
フェーズ 5 → フェーズ 6	指摘事項の重複を排除し、検証
</flow_overview>

<key_principles>

整合性：すべてのツール呼び出しは、必ず仮説の検証を支援する必要があります
検証：実際のコードのみを対象にします（使用されていない／テスト／非推奨のコードは対象外）。updated の日付を確認します。
リンク（PR モード）：コードへの参照には、必ず GitHub の完全なリンクを使用します（https://github.com/{{OWNER}}/{{REPO}}/blob/{{BRANCH}}/{{PATH}}）。
リンク（ローカルモード）：ローカルコードへの参照には file:line 形式を使用します。
改善：推論が弱い場合は、ツールまたはクエリを変更します。
効率性：Octocode MCP のクエリはまとめて実行します（1 回の呼び出しにつき 1～3 件）。内容より先にメタデータを取得します。
タスク：フルモードのレビューでは、必ずランタイムのタスク／ToDo 追跡ツールを使って進捗を管理します。
禁止：所要時間や期間の見積もりを提示すること。
禁止：指摘事項を #1、#2、#N として参照すること。GitHub が #<number> を課題／PR へのリンクに自動変換します。 </key_principles>

実行ライフサイクル

以下の詳細なライフサイクル手順を使用します：

実行ライフサイクルのリファレンス

<execution_lifecycle_base>

基本とオプション（必須）

基本（この SKILL 内）：
- 対象の検出
- ツールのモデルと選択ルール
- フロー分析プロトコル
- フェーズ 4 の分析ゲート（中核となる推論／実行）
オプション／拡張（リファレンス内）：
- 依存関係ゲートの詳細
- 各フェーズ（1、2、3、5、6）の詳細なプレイブック
- 拡張版の検証チェックリスト </execution_lifecycle_base>

フェーズ 4：分析

<analysis_gate> 必須：フェーズ 3 でのユーザーの指示と、フェーズ 1 のガイドラインを遵守してください。

前提条件

フェーズ 3（ユーザーチェックポイント）が完了している
ユーザーから指示を受け取っている（注目領域または「全体レビュー」）
ガイドラインのコンテキストを利用できる（または空であることを確認済み）

アクション（必須 — PR モードとローカルモードの両方）

モード別のツール選択（「ツール」セクションの「ツール選択ルール」を参照）：

PR モード（ワークスペースが PR リポジトリ）：local* と lsp* を主に使用し、PR メタデータ／差分には github* を使用

PR モード（ワークスペースが PR リポジトリではない）：github* のみ使用

ローカルモード：local*、lsp*、シェルの git を使用（ENABLE_LOCAL=true が必要 — 「ターゲット検出」を参照）

ファイルスコープ：ローカルモードと同じですが、すべての分析を対象ファイルとその直接の依存関係グラフ（1 ホップ）に限定

ユーザーの関心に沿った検索クエリを 3〜5 件列挙し、それぞれ実行します：
```
Query 1: [tool] — [search pattern] — [goal]
Query 2: [tool] — [search pattern] — [goal]
...
```
ガイドライン準拠チェック（フェーズ 1 でガイドラインが読み込まれている場合は必須）：
- 変更された各ファイルについて、読み込まれたガイドライン／規約に照らして確認します
- プロジェクト固有のルールへの違反があれば、該当するガイドラインを明記して必ず報告します
フロー影響分析（関数／メソッドの変更では必須）：
- 変更の種類に応じた「フロー分析プロトコル」の該当レシピを適用します（「フロー分析プロトコル」セクションと references/flow-analysis-protocol.md を参照）
- 戻り値、型、または副作用に変更があったかを必ず特定します
- 既存の連携が壊れるかどうかを必ず確認します
- 影響範囲を記録します：影響を受ける呼び出し元／利用者の数
matchString を使って、スキーマ／API／依存関係を検証します（PR モード：githubGetFileContent、ローカルモード：localGetFileContent と localSearchCode）
ドメインごとに影響を評価します（フェーズ 3 でユーザーが指定した領域を優先）：
- アーキテクチャ：システム構造、パターンとの整合性
- 連携：影響を受けるシステム、連携パターン
- リスク：競合状態、パフォーマンス、セキュリティ
- ビジネス：ユーザー体験、指標、運用コスト
- 連鎖的影響：これが別の問題を引き起こす可能性はあるか
変更されたロジックのエッジケースを特定します
セキュリティスキャン：インジェクション、XSS、データ漏えい、規制準拠
新しいコード内の TODO／FIXME コメントをスキャンします（「+」の行のみ）
高リスクの変更では：ロールバック戦略／フィーチャーフラグが必要か評価します
事前確認の提案（ローカルモードのみ）：変更が大規模な場合は、レビューを確定する前にプロジェクトのテスト／リンタースイートを実行するよう提案します

ゲートチェック

すべての検索クエリを実行した
ガイドラインへの準拠を確認した（ガイドラインが読み込まれている場合）
変更したすべての関数についてフローへの影響を分析した（ローカルモードでは LSP を使用）
ユーザーが指定したすべての関心領域を網羅した
確信度を付けた指摘事項の一覧を作成した

禁止事項

フェーズ 3 でユーザーが明示的に除外した領域の分析
関数／メソッドの変更に対するフロー影響分析の省略
フェーズ 1 で読み込まれたガイドラインの無視
ローカルモード：コードの読み取りに github* ツールを使用すること（必ず local* と lsp* を使用）
ローカルモード：先に localSearchCode を呼び出さずに lineHint を推測すること
ファイルスコープ：ユーザーの依頼なしに、対象ファイルと直接の依存関係を超えて分析範囲を広げること
ファイルスコープ：並列エージェントを起動すること（1 回限りのレビューのみ）

許可事項

PR モード：すべての Octocode MCP ツール（github*、local*、lsp*）
ローカルモード：Octocode MCP の local* と lsp* ツール、およびシェルの git コマンド
両方：大規模な変更セットでは Task を使って並列エージェントを起動する（「マルチエージェント」セクションを参照）

失敗時

検索結果がない場合 → クエリの範囲を広げる、類義語を試す、またはツールを変更する
フロー追跡が行き詰まった場合 → 制約を記録し、得られた証拠をもとに続行する
LSP ツールが失敗した場合（ローカルモード） → localSearchCode のパターンマッチングに切り替える </analysis_gate>

Phase 5 + Phase 6（詳細は任意）

ベーススキルに焦点を当てるため、Finalize/Report の詳細はライフサイクルのリファレンスに記載します：

実行ライフサイクルのリファレンス

この SKILL での基本方針：

Phase 4 の後は、影響が大きく、証拠に裏付けられた指摘のみを最終化します
簡潔な推奨事項を提示し、レビュー文書を作成する前に確認を求めます

マルチエージェントの並列化とスウォーム戦略

<parallel_execution>

エージェントの定義、プロンプトテンプレート、スケーリングルール、マージプロトコルの詳細: references/parallel-agent-protocol.md

簡易ルール：ファイル数が 5 以下の場合は単一パス（エージェントなし）。Full モードでファイル数が 5 を超える場合は、必ず並列エージェントを使用します。

PR モードとローカルモードの両方に適用されます。 ローカルモードでは、エージェントは local* と lsp* ツールのみを使用します（コードの読み取りに github* は使用しません）。

エージェント（Phase 4 で一度のメッセージですべて起動します）：

Agent A：フローへの影響 — 変更されたシンボルの呼び出し元／利用者を追跡します（ローカルモードでは lspCallHierarchy と lspFindReferences を使用）
Agent B：セキュリティとエラー処理 — 脆弱性や握りつぶされた例外を調べます
Agent C：アーキテクチャとコード品質 — パターン、結合度、パフォーマンスを調べます
Agent D：ガイドラインと重複 — ガイドラインが読み込まれている場合のみ、準拠状況と DRY を確認します

スケーリング：エージェント 2 つ（ファイル数 6～15）→ エージェント 3 つ（ファイル数 16～30）→ エージェント 4 つ（ファイル数 30 以上）。詳細なマトリクスはリファレンスを参照してください。

マージ：収集 → 重複を除外 → PR コメントと照合（PR モード）または重複のみを除外（ローカルモード）→ 優先順位付け（セキュリティ > バグ > フロー > アーキテクチャ > パフォーマンス > 品質）→ 指摘数の上限を適用（実行ライフサイクルのリファレンス、Phase 5 を参照）。

禁止事項：Quick モードでのエージェント使用、エージェントを 4 つより多く使用すること、順次起動、すべてのエージェントが結果を返す前に先へ進むこと。 </parallel_execution>

出力プロトコル

レポートテンプレートと形式の詳細: references/output-template.md

<output_structure> テンプレートのセクション：エグゼクティブサマリー（目標、リスク、推奨事項）→ 評価（正確性、セキュリティ、パフォーマンス、保守性）→ PR／変更の健全性 → ガイドラインへの準拠 → 問題（High／Medium／Low。file:line と差分形式の修正を含む）→ フローへの影響分析

各指摘に必須の項目：場所（file:line）、確信度（HIGH/MED）、問題の説明、コード修正（差分形式）

指摘のラベル

禁止事項： 出力内のどこであっても、指摘のラベル付けや参照に #1、#2、または #<number> 形式を使用すること。GitHub は #N を課題やプルリクエストへのリンクに自動変換するため、PR コメントに誤ったリンクや誤解を招くリンクが作成されます。
通常の番号（1.、2.）、文字ラベル（A、B）、または説明的なカテゴリ ID（例：[SEC-1]、[BUG-1]、[ARCH-1]）を使用してください。
これは見出し、本文中の参照、要約リスト、その他指摘 ID に言及するすべての箇所に適用されます。 </output_structure>

リファレンス

フロー分析：references/flow-analysis-protocol.md — トレース手順（ローカルとリモート向けの 6 つの手順）
ドメインレビュアー：references/domain-reviewers.md — ドメインの検出、優先順位マトリクス、除外項目
依存関係の確認：references/dependency-check.md — 事前確認のゲートと失敗時の処理の詳細
レビューガイドライン：references/review-guidelines.md — 確信度モデルと変更コードに対する考え方
実行ライフサイクル：references/execution-lifecycle.md — Phase 1、2、3、5、6 の詳細な手順
検証チェックリスト：references/verification-checklist.md — 提出前チェックリストの詳細
並列エージェント：references/parallel-agent-protocol.md — エージェントの定義、プロンプト、スケーリング、マージプロトコル
出力テンプレート：references/output-template.md — レポート形式と Markdown テンプレート

検証チェックリスト

以下の完全なチェックリストを使用してください：

検証チェックリストの参照

<verification_base>

対象／モードを特定済み（依頼された場合は、ファイルスコープのローカルチェックを含む）
フェーズ 4 の分析を、根拠と確信度ラベルを含めて完了済み
指摘事項は実行可能で、重複がなく、適切な範囲に限定されている
指摘事項のラベルや参照に #<number> 表記を使用していない </verification_base>

Markdown 対応

ログインしてコメント

基本情報

作者: bgauryy
リポジトリ: bgauryy/octocode
カテゴリ: テスト・品質
インストール数: 68
GitHub スター: 956

問題を報告