cross-review-project
について
このスキルは、専用のMCPブローカーを介して2つのClaude Codeインスタンスが構造化された相互コードレビューを実施できるようにします。最小限の証拠閾値と段階的進行を要求するQSGスケーリング則を通じて、レビュー品質を保証します。2つのコードベース間で体系的かつ証拠に基づいたクロスプロジェクト分析が必要な場合にご利用ください。
クイックインストール
Claude Code
推奨npx skills add pjt222/agent-almanac -a claude-code/plugin add https://github.com/pjt222/agent-almanacgit clone https://github.com/pjt222/agent-almanac.git ~/.claude/skills/cross-review-projectこのコマンドをClaude Codeにコピー&ペーストしてスキルをインストールします
ドキュメント
Cross-Review Project
2 Claude Code instances review each other via cross-review-mcp broker. QSG scaling laws enforce quality: bundles ≥5 findings → selection regime (Γ_h ≈ 1.67), prevents shallow consensus.
Use When
- 2 projects share arch concerns
- Indep review beyond 1 reviewer
- Cross-pollinate: find patterns missing in other
- Structured evidence-backed verdicts (accept/reject/discuss)
In
- Required: 2 project paths, 2 Claude Code instances
- Required:
cross-review-mcpbroker + MCP server in both - Optional: Focus areas (dirs, patterns, concerns)
- Optional: Agent IDs (def: project dir name)
Do
Step 1: Prereqs
Broker running + both instances reach it.
- Broker configured:
claude mcp list | grep cross-review - Call
get_status→ responsive + no stale agents - Read
cross-review://protocol— markdown doc w/ dims + QSG constraints
Got: Broker responds w/ empty agent list. Protocol readable.
If err: Not configured → claude mcp add cross-review-mcp -- npx cross-review-mcp. Stale agents → deregister each first.
Step 2: Register
- Call
register:agentId: short unique ID (project dir name)project: project namecapabilities:["review", "suggest"]
- Verify:
get_status→ agent at phase"registered" - Wait for peer:
wait_for_phasew/ peer ID + phase"registered"
Got: Both registered. get_status → 2 agents @ "registered".
If err: register fails "already registered" → ID taken from prior. deregister first + re-register.
Step 3: Briefing
Read own codebase, send structured briefing → peer.
- Systematic read:
- Entry pts (main, index, CLI)
- Dep graph (package.json, DESCRIPTION, go.mod)
- Arch patterns (dirs, modules)
- Known issues (TODOs, issues, debt)
- Test coverage (tests, CI)
- Compose
Briefing— structured summary → peer navigates efficiently send_task:from: your IDto: peer IDtype:"briefing"payload: JSON briefing
signal_phase→"briefing"
Got: Briefing sent + phase signaled. Broker enforces briefing pre-review.
If err: send_task rejects → from must = registered ID. Self-sends rejected.
Step 4: Review
Wait peer briefing, review their code, send findings.
wait_for_phasepeer ID +"briefing"poll_tasks→ peer's briefingack_tasksw/ task IDs (peek-then-ack req)- Read peer's src, informed by briefing
- Findings, 6 cats:
pattern_transfer— pattern in yours peer could adoptmissing_practice— practice peer lacks (testing, valid., err handling)inconsistency— internal contradiction in peersimplification— unnecessary complexitybug_risk— potential runtime fail / edge casedocumentation_gap— missing / misleading docs
- Each finding:
id: unique ("F-001")category: 1 of 6targetFile: path in peerdescription: what foundevidence: why valid (code refs, patterns)sourceAnalog(rec): equivalent in yours → single mech for genuine cross-pollination
- Bundle ≥5 findings (QSG: m ≥ 5 keeps Γ_h ≈ 1.67 selection regime)
send_tasktype"review_bundle"+ JSON findings arraysignal_phase→"review"
Got: Bundle accepted. <5 → rejected.
If err: Rejected for <5 → review deeper. Constraint prevents shallow dominating. Can't find 5 → reconsider if cross-review fits.
Step 5: Dialogue
Receive findings about yours → respond w/ verdicts.
wait_for_phasepeer +"review"poll_tasks→ findings about yoursack_tasks- Per finding,
FindingResponse:findingId: matches finding's IDverdict:"accept"(valid, will act) /"reject"(invalid + counter-evidence) /"discuss"(needs clarify)evidence: why accept/reject — must be non-emptycounterEvidence(opt): code refs contradicting
- Send all →
send_tasktype"response" signal_phase→"dialogue"
Note: "discuss" not gated → flag for manual follow-up, not auto sub-exchange.
Got: All findings → verdict. Empty → rejected.
If err: Can't form opinion → default "discuss" + evidence explaining what context needed.
Step 6: Synthesis
Produce synth artifact: accepted findings + planned actions.
wait_for_phasepeer +"dialogue"- Poll remaining + ack
- Compile
Synthesis:- Accepted + planned actions (what change + why)
- Rejected + reasons (preserves reasoning)
send_tasktype"synthesis"+ JSON synthsignal_phase→"synthesis"- Optional: create GH issues for accepted
signal_phase→"complete"deregister→ cleanup
Got: Both reach "complete". Broker req ≥2 registered to advance.
If err: Peer already deregistered → complete locally. Compile synth from received.
Check
- Both registered + reached
"complete" - Briefings exchanged pre-review (phase enforced)
- Bundles ≥5 findings each
- All findings → verdict + evidence
-
ack_tasksafter everypoll_tasks - Synth produced + actions mapped
- Deregistered post-complete
Traps
- <5 findings: Broker rejects m<5. Not arbitrary — N=2 agents × 6 cats, m<5 → Γ_h at/below critical → consensus = noise. Review deeper; can't find 5 → projects may not benefit.
- Forgot
ack_tasks: Peek-then-ack delivery. Tasks stay in queue until acked. Forget → dup processing on next poll. - Forgot
fromparam:send_taskneeds explicitfrom= your ID. Self-sends rejected. - Same-model epistemic correlation: 2 Claude share training biases. Temporal ordering prevents reading during review, but priors correlated. Genuine epistemic indep → diff model families.
- Skip
sourceAnalog: Optional but single mech for genuine cross-pollination — shows your impl of pattern. Populate when exists. - Treat
discussas blocking: Protocol doesn't gatecompleteon pending discussions. Flag for manual follow-up post-session. - Skip telemetry: Broker logs all → JSONL. Post-session, validate QSG: estimate α empirical (
α ≈ 1 - reject_rate) + check per-cat accept rates.
→
scaffold-mcp-server— build/extend brokerimplement-a2a-server— A2A patterns broker draws fromreview-codebase— single-agent (this extends → cross-agent structured)build-consensus— swarm consensus (QSG theoretical foundation)configure-mcp-server— broker as MCP in Claude Codeunleash-the-agents— analyze broker itself (battle-tested: 40 agents, 10 hypothesis families)
GitHub リポジトリ
関連スキル
qmd
開発qmdは、BM25、ベクトル埋め込み、およびリランキングを組み合わせたハイブリッド検索を用いて、ローカルファイルのインデックス作成と検索を可能にするローカル検索・インデックス作成CLIツールです。コマンドラインでの使用と、Claudeとの統合のためのMCP(Model Context Protocol)モードの両方をサポートしています。このツールは埋め込みにOllamaを使用し、インデックスをローカルに保存するため、ターミナルから直接ドキュメントやコードベースを検索するのに最適です。
subagent-driven-development
開発このスキルは、各独立したタスクに対して新規のサブエージェントを起動し、タスク間でコードレビューを実施しながら実装計画を実行します。レビュープロセスを通じて品質基準を維持しつつ、迅速な反復を可能にします。同一セッション内で主に独立したタスクに取り組む際に本スキルをご利用いただくことで、組み込まれた品質チェックを伴う継続的な進捗を確保できます。
mcporter
開発mcporterスキルは、開発者がClaudeから直接Model Context Protocol(MCP)サーバーを管理および呼び出せるようにします。このスキルは、利用可能なサーバーの一覧表示、引数を指定したツールの呼び出し、認証およびデーモンのライフサイクル管理を行うコマンドを提供します。開発ワークフローにおいてMCPサーバーの機能を統合およびテストする際に、このスキルをご利用ください。
adk-deployment-specialist
開発このスキルは、A2Aプロトコルを使用してVertex AI ADKエージェントをデプロイおよびオーケストレーションし、AgentCardの発見、タスク送信、およびコード実行サンドボックスやメモリバンクなどのサポートツールを管理します。Python、Java、またはGoで、順次、並列、またはループのオーケストレーションパターンを用いたマルチエージェントシステムの構築を可能にします。Google Cloud上でADKエージェントのデプロイやエージェントワークフローのオーケストレーションを求められた際にご利用ください。
