mcpField
C
code-quorum

code-quorum

github.com/scottwaterテスト・品質167 回インストール1 週間前に更新
リポジトリ

code-quorum について

code-quorumは、ランタイムのネイティブなサブエージェント機能でブラインドレビューを調整する読み取り専用のコードレビュー用スキルです。対象ファイルを変更せず、指摘を統合・検証して報告します。

主な機能

  1. 01読み取り専用のレビュー手順
  2. 02ブラインドなレビュアー用サブエージェント
  3. 03範囲とレビュアーの選定
  4. 04指摘の正規化と統合
  5. 05証拠に基づく検証と報告

活用シーン

  1. 01指定したコード差分のレビュー
  2. 02要件に照らした変更の確認
  3. 03ワークスペースを変更しないレビュー報告

インストール

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

$npx skills add https://github.com/scottwater/skills --skill code-quorum

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

同梱ファイル

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

agents/
openai.yaml
references/reviewers/
correctness-reviewer.md
failure-mode-reviewer.md
requirements-reviewer.md
silent-failure-hunter.md
simplification-reviewer.md
test-behavior-reviewer.md

詳細

読み取り専用の境界

ワークフロー全体では、調査と報告のみを行います。ワークフロー内のエージェントは、レビュー対象のファイルを編集したり、パッチを生成または適用したり、コミットしたり、修正に着手したりしません。推奨事項は、後から個別に承認されるワークフローを対象とします。根拠となる主張は、変更を加えないコマンド、またはレビュー対象のワークスペースに影響を与えない使い捨ての隔離環境でのみ再現してください。

エージェントを確認する

レビュー対象の範囲に触れる前に、ワーカーの仕組みを確認します。

クォーラム全体には、ランタイム標準のサブエージェント抽象化を使用します。以下のレビュアー名は評価基準であり、設定済みエージェントの名前を指定するものではありません。選択した評価基準ごとに、新しいブラインドの子エージェントを1つ作成し、その評価基準をタスクパケットに含めてください。

すべてのレビュアーはブラインドエージェントとします。コンテキストを新規にし、過去の結論や、委任元のコンテキストにあるレビュー結果を与えないでください。同時実行は任意ですが、ブラインドであることは必須です。ブラインドエージェントを作成できる仕組みがない場合は停止し、利用できない機能を明記した実行不可の応答を返してください。

このステップは、レビュアーごとにブラインドエージェントを作成できる仕組みが1つ確認できた時点で完了です。

範囲を特定する

まず明示された範囲を特定します。明示されていない場合は、次の順に特定します。HEAD に対する未確定の変更(ステージ済みの変更を含む)、ステージされていない追跡対象の変更、関連する未追跡ファイル、マージベースからのブランチ、関連付けられたプルリクエスト、最近のコミット、名前が指定されたタスク成果物。提示または関連付けられた課題、プルリクエストの説明、仕様、受け入れ基準があれば、要件の情報源として記録します。ない場合は、その旨を記録します。リポジトリ全体のレビューを推測してはいけません。推測された範囲が異常に大きい場合は、その旨を指摘してください。

このステップは、正確な差分、範囲、またはファイルと、要件の情報源の有無を明記できた時点で完了です。

レビュアーを選択する

明示されたレビュアー名を、名前付きセットより優先し、名前付きセットをデフォルトのセットより優先します。ユーザーが指定した重点事項、追加項目、除外項目を適用します。simple と lightweight は quick のエイリアスとして扱います。

quick:
  - correctness-reviewer
  - silent-failure-hunter
default:
  - correctness-reviewer
  - failure-mode-reviewer
  - silent-failure-hunter
full:
  - correctness-reviewer
  - failure-mode-reviewer
  - silent-failure-hunter
  - simplification-reviewer
  - test-behavior-reviewer

除外されていない場合、要件の情報源にテスト可能な動作が記載されているセットには、requirements-reviewer を追加します。references/reviewers/ からは、選択したファイルのみを読み込みます。

このステップは、選択が一通りに定まり、選択したすべてのレビュアーに適用可能な評価基準がある時点で完了です。

クォーラムを実行する

すべてのレビュアーに、同一のタスクパケットを渡します。タスクパケットには、範囲、情報源、変更されたファイル、要件の情報源またはその不在、重点事項、除外項目、プロジェクトルール、読み取り専用の指定、指摘事項の形式を含め、さらに各レビュアー固有の評価基準を1つ加えます。評価基準のエビデンス基準を満たすすべての重要な候補を重大度順に報告するよう求めます。該当する候補がない場合は、no_findings をレビュー完了とします。確認済みの仕組みを通じて、レビュアーごとにブラインドエージェントを1つ作成します。可能な場合は同時に、そうでない場合は順次作成します。

ワーカーの仕組みに受け入れゲートがある場合は、無効にしてください。受け入れ層はレビュアーであり、ゲートによって有効なレビュアーの出力が誤って失敗になることがあります。

すべてのレビュアーが応答、失敗、またはタイムアウトするまで待ちます。各結果は、ラッパーのライフサイクルラベルではなく、返された報告内容で判定します。ラッパーが異常を示していても、報告が完全であれば保持し、その異常をレビュー範囲の制約に記載します。欠落したレビュアーがもたらすのはレビュー範囲の制約のみであり、合意や no_findings として扱ってはいけません。使用可能な結果を返したレビュアーがいない場合は、実行失敗を返します。

このステップは、選択したすべてのレビュアーについて、使用可能な結果または記録された失敗理由が揃い、かつ少なくとも1つの使用可能な結果がある時点で完了です。

候補を正規化する

すべての候補を finding-v1 に正規化します。

title: Concrete failure or concern
location: { file: path/to/file, lines: 10-18 }
category: correctness
severity: critical | high | medium | low
claim: What is wrong
trigger: Conditions that expose it
impact: Resulting behavior or risk
evidence: [Relevant code-path evidence]
recommendation: Direction for addressing it
source_reviewers: [reviewer-name]

すべてのフィールドを必須とします。source_reviewers には、各レビュアー自身の報告に実質的に同等の主張が含まれているレビュアーのみを列挙します。選択されたというだけでは、帰属を示す根拠になりません。このステップは、すべての候補が形式に準拠するか、却下理由が記録された時点で完了です。

統合

根本原因ごとに候補を統合します。スタイルのみの指摘、推測に基づく指摘、既存の指摘、スコープ外の指摘は除外します。意見の相違はソースの証拠に基づいて解決します。2人目のレビュアーによる指摘を裏付けとして数えるのは、実質的に独立した証拠、異なるトリガー、または異なる障害モードが提示されている場合に限ります。

各候補が、保持する候補に統合されるか、理由を付して却下された時点で、このステップは完了です。

検証

保持する候補すべてについて、ソース、保護策、テストに照らして解決します。適切な範囲で検証します。関連するコードパスをたどり、呼び出し元と契約を調べ、信頼できるフレームワークまたはプラットフォームの動作を確認し、指摘内容に応じて再現します。verified、partially-verified、unresolved、rejectedを割り当て、手法と証拠を記録します。重要な未解決候補は、解決に必要な証拠とともに「未解決の質問」に移します。

保持するすべての候補にステータス、手法、証拠、報告先または却下理由が記録された時点で、このステップは完了です。

優先順位付けと報告

以下の標準的な意味に基づいて重大度を割り当てます。

  • critical:壊滅的、差し迫った危険、または取り消し不能な影響。
  • high:重大で、リリースを阻止する不具合。
  • medium:重要な不具合で、通常はリリースを阻止しないもの。
  • low:軽微なリスク、または価値のある改善。

報告の下限はmediumとします。ユーザーがすべての推奨事項を明示的に求めた場合に限り、下限をlowに引き下げます。判定とすべての報告セクションは、報告の下限を満たす候補のみから作成します。下限に満たない候補は、判定に影響させず、黙って除外します。

重大度、検証状況、処置区分は分けて扱います。処置区分の意味は次のとおりです。

  • block:検証済みの重大な指摘。
  • address:既知の影響がリリースを阻止しない、検証済みまたは一部検証済みの、対応可能な指摘。
  • consider:選定された簡素化レビュアーによる、検証済みの低リスクな簡素化。

重要な未解決候補と、リリースを阻止する可能性のある一部検証済み候補は、「未解決の質問」にのみ記載します。解決に必要な証拠を明記し、判定から除外します。ユーザーが経緯の提示を求めない限り、却下した指摘は省略します。P0~P3の別名は、要求された場合に限り使用します。

以下のテンプレートどおりにレポートを作成します。各セクションは順序どおりに一度だけ記載し、「検討事項」と「未解決の質問」は空の場合に省略します。

## Verdict

<One sentence: **Merge**, **Merge after fixes**, or **Do not merge** — with the deciding reason.>

Scope: <range/PR · files · +/− lines> · Reviewers: <usable/selected> (<mechanism>)

## Do next

- [ ] `path/to/file:lines` — <imperative action> (finding 1)

## Findings

### 1. <Concrete failure in plain words> — <severity> · <disposition>

- **Where:** `path/to/file:lines` — <function or block name>
- **What:** <claim and trigger, at most two sentences>
- **Impact:** <resulting behavior or risk, one sentence>
- **Fix:** <one imperative sentence>
- **Verification:** <status> · <source reviewers>

## Consider

- `path/to/file:lines` — <one-line suggestion> (<source reviewers>)

## Open questions

- <Unresolved claim> — <the evidence that would settle it>

## Coverage

<Isolation, reviewer failures, and limitations in two or three lines.>

「次に行うこと」の各項目と各指摘には、正確なfile:linesの場所を記載します。レビュアーがファイル名またはブロック名のみを示した場合は、報告前にソースから行番号を特定します。「次に行うこと」には、すべてのblock項目とaddress項目を重大度順に並べ、1項目につき命令文を1行で記載します。簡素化レビュアーによる検証済みのconsider項目は、「検討事項」にのみ記載します。チェックリストと詳細を番号で相互参照できるよう、指摘には「次に行うこと」の順で番号を付けます。

レポートがテンプレートに一致した時点で、このステップは完了です。報告する候補はすべて報告の下限を満たし、すべての指摘に重大度、検証状況、処置区分があり、すべての指摘、「次に行うこと」の項目、「検討事項」の項目に正確なfile:linesの場所があり、すべての指摘に1文で修正方法が示され、「次に行うこと」の各項目に該当する指摘が記載され、未解決の質問には解決に必要な証拠が示されています。

コメント