cross-review-project
Über
Diese Fähigkeit ermöglicht es zwei Claude Code-Instanzen, strukturierte, wechselseitige Code-Reviews über einen dedizierten MCP-Broker durchzuführen. Sie erzwingt die Review-Qualität durch QSG-Skalierungsgesetze, die Mindestnachweisschwellen und phasengesteuerten Fortschritt erfordern. Nutzen Sie sie, wenn Sie eine systematische, evidenzgestützte Analyse zwischen zwei Codebasen benötigen.
Schnellinstallation
Claude Code
Empfohlennpx 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-projectKopieren Sie diesen Befehl und fügen Sie ihn in Claude Code ein, um diese Fähigkeit zu installieren
Dokumentation
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 Repository
Verwandte Skills
qmd
Entwicklungqmd ist ein lokales Such- und Indexierungs-CLI-Tool, das Entwicklern ermöglicht, lokale Dateien mittels Hybridsuche zu indexieren und zu durchsuchen, die BM25, Vektoreinbettungen und Neuordnung kombiniert. Es unterstützt sowohl die Kommandozeilennutzung als auch den MCP-Modus (Model Context Protocol) zur Integration mit Claude. Das Tool verwendet Ollama für Einbettungen und speichert Indizes lokal, was es ideal für die direkte Suche in Dokumentationen oder Codebasen vom Terminal aus macht.
subagent-driven-development
EntwicklungDiese Fähigkeit führt Implementierungspläne aus, indem für jede unabhängige Aufgabe ein neuer Subagent bereitgestellt wird, mit Code-Review zwischen den Aufgaben. Sie ermöglicht schnelle Iterationen, während Qualitätssicherungsschritte durch diesen Review-Prozess gewahrt bleiben. Nutzen Sie sie, wenn Sie überwiegend unabhängige Aufgaben innerhalb derselben Sitzung bearbeiten, um kontinuierlichen Fortschritt mit integrierten Qualitätsprüfungen zu gewährleisten.
mcporter
EntwicklungDie mcporter-Skill ermöglicht es Entwicklern, Model Context Protocol (MCP)-Server direkt aus Claude heraus zu verwalten und aufzurufen. Sie bietet Befehle, um verfügbare Server aufzulisten, deren Tools mit Argumenten aufzurufen sowie Authentifizierung und Daemon-Lebenszyklus zu handhaben. Nutzen Sie diese Skill, um MCP-Server-Funktionalität in Ihren Entwicklungs-Workflow zu integrieren und zu testen.
adk-deployment-specialist
EntwicklungDiese Fähigkeit stellt Vertex AI ADK-Agenten über das A2A-Protokoll bereit und orchestriert sie, verwaltet die AgentCard-Erkennung, Aufgabenübermittlung und unterstützende Tools wie die Code Execution Sandbox und Memory Bank. Sie ermöglicht den Aufbau von Multi-Agenten-Systemen mit sequenziellen, parallelen oder Schleifen-Orchestrierungsmustern in Python, Java oder Go. Verwenden Sie sie, wenn Sie aufgefordert werden, ADK-Agenten bereitzustellen oder Agenten-Workflows auf Google Cloud zu orchestrieren.
