MCP HubMCP Hub
스킬 목록으로 돌아가기

cross-review-project

pjt222
업데이트됨 2 days ago
5 조회
17
2
17
GitHub에서 보기
개발aimcp

정보

이 스킬은 전용 MCP 브로커를 통해 두 개의 Claude Code 인스턴스가 구조화된 상호 코드 리뷰를 수행할 수 있도록 합니다. 최소 증거 기준과 단계별 진행을 요구하는 QSG 스케일링 법칙을 통해 리뷰 품질을 강제합니다. 두 코드베이스 간에 체계적이고 증거 기반의 교차 프로젝트 분석이 필요할 때 사용하세요.

빠른 설치

Claude Code

추천
기본
npx skills add pjt222/agent-almanac -a claude-code
플러그인 명령대체
/plugin add https://github.com/pjt222/agent-almanac
Git 클론대체
git 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-mcp broker + 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.

  1. Broker configured:
    claude mcp list | grep cross-review
    
  2. Call get_status → responsive + no stale agents
  3. 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

  1. Call register:
    • agentId: short unique ID (project dir name)
    • project: project name
    • capabilities: ["review", "suggest"]
  2. Verify: get_status → agent at phase "registered"
  3. Wait for peer: wait_for_phase w/ 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.

  1. 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)
  2. Compose Briefing — structured summary → peer navigates efficiently
  3. send_task:
    • from: your ID
    • to: peer ID
    • type: "briefing"
    • payload: JSON briefing
  4. 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.

  1. wait_for_phase peer ID + "briefing"
  2. poll_tasks → peer's briefing
  3. ack_tasks w/ task IDs (peek-then-ack req)
  4. Read peer's src, informed by briefing
  5. Findings, 6 cats:
    • pattern_transfer — pattern in yours peer could adopt
    • missing_practice — practice peer lacks (testing, valid., err handling)
    • inconsistency — internal contradiction in peer
    • simplification — unnecessary complexity
    • bug_risk — potential runtime fail / edge case
    • documentation_gap — missing / misleading docs
  6. Each finding:
    • id: unique ("F-001")
    • category: 1 of 6
    • targetFile: path in peer
    • description: what found
    • evidence: why valid (code refs, patterns)
    • sourceAnalog (rec): equivalent in yours → single mech for genuine cross-pollination
  7. Bundle ≥5 findings (QSG: m ≥ 5 keeps Γ_h ≈ 1.67 selection regime)
  8. send_task type "review_bundle" + JSON findings array
  9. signal_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.

  1. wait_for_phase peer + "review"
  2. poll_tasks → findings about yours
  3. ack_tasks
  4. Per finding, FindingResponse:
    • findingId: matches finding's ID
    • verdict: "accept" (valid, will act) / "reject" (invalid + counter-evidence) / "discuss" (needs clarify)
    • evidence: why accept/reject — must be non-empty
    • counterEvidence (opt): code refs contradicting
  5. Send all → send_task type "response"
  6. 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.

  1. wait_for_phase peer + "dialogue"
  2. Poll remaining + ack
  3. Compile Synthesis:
    • Accepted + planned actions (what change + why)
    • Rejected + reasons (preserves reasoning)
  4. send_task type "synthesis" + JSON synth
  5. signal_phase"synthesis"
  6. Optional: create GH issues for accepted
  7. signal_phase"complete"
  8. 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_tasks after every poll_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 from param: send_task needs explicit from = 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 discuss as blocking: Protocol doesn't gate complete on 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 broker
  • implement-a2a-server — A2A patterns broker draws from
  • review-codebase — single-agent (this extends → cross-agent structured)
  • build-consensus — swarm consensus (QSG theoretical foundation)
  • configure-mcp-server — broker as MCP in Claude Code
  • unleash-the-agents — analyze broker itself (battle-tested: 40 agents, 10 hypothesis families)

GitHub 저장소

pjt222/agent-almanac
경로: i18n/caveman-ultra/skills/cross-review-project
0
agentsagentskillsai-assisted-developmentclaude-codeskillsteams

연관 스킬

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 에이전트 배포 또는 에이전트 워크플로우 오케스트레이션을 요청받았을 때 사용하세요.

스킬 보기