GitNexus PR Reviewer SwarmClaude Code 下的七角色只读 PR 评审蜂群适配器【免费下载链接】GitNexusGitNexus: The Zero-Server Code Intelligence Engine - GitNexus is a client-side knowledge graph creator that runs entirely in your browser. Drop in a git repository (Github, Gitlab, Azure, Local) or ZIP file, and get an interactive knowledge graph with a built in Graph RAG Agent. Perfect for code exploration项目地址: https://gitcode.com/GitHub_Trending/gi/GitNexusGitNexus 仓库为「生产就绪度 PR 评审蜂群」提供了一套跨 CLI 的共享评审契约pr-swarm-review/而.claude/README-gitnexus-reviewer-swarm.md描述的是其中 Claude Code 的专属入口一个协调者 Skill 加七个薄 Subagent 包装器。读完本文你将掌握如何在 Claude Code 中以 Swarm 模式调用/gitnexus-pr-swarm-review、七个子代理的 frontmatter 配置与模型分层如何落地、协调者如何按编排契约调度各评审泳道lane以及该适配器与/gitnexus-review的 CI 评审泳道之间的边界。定位Claude Code 适配器只是入口评审逻辑在 pr-swarm-review/文档开宗明义这是跨 CLI 的 GitNexus PR 评审蜂群在 Claude Code 中的 entrypoint。评审逻辑本身与 CLI 无关全部存放在pr-swarm-review/目录下——那个 README 才是 canonical唯一权威指南覆盖所有 CLIClaude Code、Gemini、Copilot、Cursor、Codex 以及任何支持 AGENTS.md 的 agent。这一「单一事实源 薄适配器」的设计在仓库中体现为三个层次Canonical 契约pr-swarm-review/orchestration.md协调者契约Swarm/Solo 模式、泳道依赖、分类枚举、输出结构与pr-swarm-review/personas/下的 7 个 persona 文件Claude Code 适配器.claude/skills/gitnexus-pr-swarm-review/SKILL.md协调者.claude/agents/gitnexus-*.md7 个薄 Subagent 包装器其他 CLI 的更薄入口Gemini 的 TOML 命令、Copilot 的 prompt、Cursor 的 command、Codex 经AGENTS.md或用户级 prompt 调用它们都只做一件事——运行时读取 orchestration 契约并遵循它。调用方式与 Swarm 模式执行流在 Claude Code 中调用方式是/gitnexus-pr-swarm-review PR URL or PR number它会以Swarm 模式运行协调者 Skill 通过 Agent 工具并行分派 7 个gitnexus-*子代理执行顺序有严格约束——Lanes 1–2 先行Lane 1PR 事实与仓库历史调查无依赖Lane 2分支卫生评审依赖 Lane 1 的输出二者的产出喂给其余泳道Lanes 3–6 并行风险架构师、测试/CI 验证器、安全边界审查者、Docs/DoD 审查者在 1–2 完成后并行执行彼此无依赖Lane 7 最后且是硬门禁synthesis critic综合批评者在草稿上运行只要其 Required corrections before posting 小节非空就不得输出最终评审必须修订后重跑 Lane 7。七个泳道的完整定义含依赖关系在 orchestration.md 的 Lanes 表 中LanePersona 文件职责依赖101-pr-facts-historian.mdPR 身份、可见状态、变更文件、关联 issue、相关 PR/commit、仓库历史、可见性缺口—202-branch-hygiene-reviewer.mdMerge-state 分支卫生分类1303-risk-architect.md生产失败模式、领域特定阻塞项1, 2404-test-ci-verifier.md测试覆盖、CI 接线、验证缺口1505-security-boundary-reviewer.md信任边界、密钥、注入、权限、隐藏 Unicode1606-docs-dod-reviewer.mdPR 专属 DoD、文档/发布说明义务1707-synthesis-critic.md评审草稿在发出前的自我批评1–6 草稿对不支持并行子代理的运行时orchestration 契约定义了等价的Solo 模式单 agent 按依赖顺序依次扮演每个 persona输出契约与 Swarm 模式完全一致。Claude Code 适配器SKILL.md只固定了 Claude Code 特有的一小撮约束运行在 Swarm 模式、Lane 7 为硬门禁、保持只读并明确要求不要把这个评审压扁成一份通用 checklist。适配器文件清单协调者与七个薄包装器文档给出了适配器的文件清单其实际内容可在仓库中逐一对应文件角色.claude/skills/gitnexus-pr-swarm-review/SKILL.md协调者——按pr-swarm-review/orchestration.md运行 Swarm 模式.claude/agents/gitnexus-*.md七个薄 Subagent 包装器各自运行时用 Read 工具读取pr-swarm-review/personas/下的 canonical persona每个包装器保留合法的 Claude Code frontmattername、description、tools、model、maxTurns。以 Lane 1 的子代理 为例--- name: gitnexus-pr-facts-historian description: GitNexus PR facts and repository-history investigator. Use to gather PR identity, visible GitHub state, changed files, commits, linked issues, related PRs, historical fixes, regressions, stale follow-ups, and missing visibility. tools: - Read - Grep - Glob - Bash model: claude-sonnet-4-6 maxTurns: 40 ---文档提到机械验证类泳道test-ci-verifier、branch-hygiene-reviewer跑在 Haiku 上分析类泳道跑在 Sonnet 上。从仓库实际的 frontmatter 可以确认这一模型分层的完整落地子代理对应 Lane模型maxTurns分层意图gitnexus-pr-facts-historian1claude-sonnet-4-640分析类事实采集 仓库历史检索gitnexus-branch-hygiene-reviewer2claude-haiku-4-5-2025100130机械类merge-state 分类gitnexus-risk-architect3claude-sonnet-4-640分析类生产失败模式gitnexus-test-ci-verifier4claude-haiku-4-5-2025100135机械类测试/CI 核对gitnexus-security-boundary-reviewer5claude-sonnet-4-635分析类信任边界gitnexus-docs-dod-reviewer6claude-sonnet-4-630分析类DoD 义务gitnexus-synthesis-critic7claude-sonnet-4-625分析类草稿批评门禁所有 7 个子代理的tools均被限制为Read / Grep / Glob / Bash四项——这是文档中 Tools limited to Read/Grep/Glob/Bash 在源码层面的直接体现。只读约束的源码级落地Bash 白名单/黑名单文档说每个 persona 强制执行显式的 Bash 允许/禁止清单没有任何 agent 编辑文件、提交或发帖。这条约束在 每个 persona 文件和子代理包装器中都以同样的措辞落地允许Bash 只读git log、git diff、git show、git grep、git ls-files、gh pr view、gh pr diff、gh pr checks、gh issue view以及检查类工具grep、cat、find、ls禁止任何写文件的命令、任何修改 git 状态的命令git commit、git add、git checkout -- path、任何向 GitHub 发帖的命令gh pr comment、gh pr review、gh issue comment、安装依赖包、运行任意脚本。此外文档还指出这是交互式蜂群相比之下CI 评审 agent 的ci-personas/泳道约束更紧——只有文件读取加上安全的图查询工具连 Grep/Glob/Bash 都不给。其余三条关键属性同样逐字继承自 pr-swarm-review/README.mdEvidence-grounded证据落地每条 finding 必须引用文件、行区间、检查、issue/PR 引用或命令缺失可见性变成验证工作看不到什么就把它列为强制验证项而不是编造事实orchestration 甚至规定了可见性不完整时必须在评审前附一句固定措辞的免责声明手动触发没有 hook 或任何自动触发。评审输出契约12 节结构与三组枚举分类为了让不同 CLI、不同模型跑出的评审可被机器与人类一致地验收orchestration 契约把最终评审钉死在固定结构上。最终评审必须按顺序包含 12 个章节Review bar for this PR—— 由仓库 DoD 推导出的验收标准Problem being solved—— PR 声称要修复/新增什么Current PR state—— draft / open / merged / closedMerge status and mergeability—— merge-state 分类 证据Repository history considered—— 相关 PR、issue、历史修复Branch hygiene assessment—— 分支卫生分类 证据Understanding of the change—— PR 实际做了什么Findings—— 全部泳道的发现统一使用 Finding 格式PR-specific assessment sections—— 与本 PR 相关的领域专项评估Back-and-forth avoided by verifying—— 直接核实、省掉来回追问的事实Open questions—— 仅在验证后仍不可避免时列出Final verdict—— 四选一附 3–6 句论证同时有三组互斥枚举分类各必须恰好取一个值Branch hygieneclean feature/fix PR·merge-from-main commit present but harmless and merge-safe·polluted by unrelated merge/churn·rebase/split requiredMerge statemergeable·blocked by conflicts·checks pending·checks failing·review blocked·draft/WIP·merged·closed without merge·visibility incompleteFinal verdictproduction-ready·production-ready with minor follow-ups·not production-ready·rebase/split required before final review每条 finding 统一使用四段格式- **Risk:** [生产风险] - **Evidence to check:** [具体文件、行区间、命令或检查] - **Recommended fix:** [应当做什么] - **Blocks merge:** yes / no / maybe契约还内置了可执行的卫生检查命令隐藏 Unicode / bidi 控制字符扫描并要求普通可见标点不阻塞但可执行代码、测试、YAML、Dockerfile、查询串、正则、安全注释中的隐藏/双向控制字符必须阻塞若未发现问题必须原样输出No production-readiness issues found against the current DoD bar.。Lane 7 的 synthesis critic persona 正是围绕这套契约工作它检查缺失证据、无依据断言、跑题内容、枚举合规性输出 Required corrections before posting——这就是硬门禁的判定依据。评审行为的红线规则orchestration 契约把评审行为本身也纳入了约束见 orchestration.md 的 Review behavior 一节永不编造事实只用当前可见状态把不确定性转化为强制验证工作优先级风险模型第一PR 事实第二仓库历史第三区分已确认发现与未验证怀疑引用文件、行区间、检查、issue/PR 参考或所用命令除非理解本 PR 风险所必需不评审无关的 GitNexus 区域将混入的无关变更视为可疑无关的 workflow 清理、release/版本号变更、parser Web UI 重构、Docker/CI 折腾、与生产行为变更混在一起的测试去抖当领域间无因果连接时要求拆分或 rebase单条生产关键泳道可以阻塞整个 PR。评审开始前还应先读取仓库的DoD.md、AGENTS.md、GUARDRAILS.md、CONTRIBUTING.md、TESTING.md、ARCHITECTURE.md若存在缺失则记一笔并退而使用最接近的可用规范。修改评审行为改 canonical 文件然后重启 Claude Code文档的 Editing 一节给出了两条维护规则只改 canonical 文件评审行为的修改点在pr-swarm-review/下的 orchestration personas而不是.claude/里的包装器。每个 persona 文件头部也有同样的注释提醒Edit this file, not the per-CLI wrappers。这样同一份评审逻辑才能被 Claude Code、Gemini、Copilot 等所有入口共享重启 Claude Code在.claude/agents/下新增或编辑文件后必须重启 Claude Code 使其重新加载 agent 定义否则新配置不生效。若未来要扩展到新 CLIpr-swarm-review/README.md 给出的原则是为目标的命令/prompt 格式加一个薄 wrapper其正文只写读取pr-swarm-review/orchestration.md并执行运行时支持并行子代理则 Swarm 模式否则 Solo 模式不要把 persona/orchestration 文本复制进 wrapper。与 /gitnexus-review 的关系区分点在 runner不在 roster文档最后说明了两套评审能力的共存关系。二者现在都运行评审者蜂群因此区别在于 runner 而不是 roster/gitnexus-pr-swarm-review本文主题交互式、按需调用的生产就绪度蜂群你直接 invoke其 criticLane 7是必须清零才能发评审的硬门禁/gitnexus-review基于 GitNexus 图MCP 工具的评审 skill覆盖 PR、分支、commit 区间或本地变更它内置的ci-personas/泳道ci-correctness-lens、ci-security-lens、ci-blast-radius-lens、ci-coverage-lens、ci-adversarial-lens五个 finder 泳道 ci-critic-lens门禁由 CI 评审 agent 在单次 workflow 运行中自动分派。一个值得注意的对照出自 gitnexus-review 的 SKILL.mdCI 泳道的 critic 采用fail-open设计——最多两轮批评修复仍有余数则记录未解决异议后照常发出评审批评强化评审但永不阻塞评审因为 CI 场景必须保证发出评审或显式失败而交互式gitnexus-pr-swarm-review的 critic 是必须通过才能 emit 的硬门禁。这正是同一个 roster 思想、不同 runner 语义的具体体现交互场景宁可不发也不发带缺陷的草稿CI 场景宁可标注也不让整个流程卡死。小结.claude/README-gitnexus-reviewer-swarm.md这个短文档的价值在于明确了 Claude Code 适配器在整个蜂群体系中的精确位置它只固定三件 Claude Code 特有的事Swarm 模式分派、Lane 7 硬门禁、只读把评审逻辑全部委托给 pr-swarm-review/ 下的 canonical 契约与 personas七个.claude/agents/gitnexus-*.md包装器仅承载 frontmatterRead/Grep/Glob/Bash 工具集、Sonnet/Haiku 模型分层、maxTurns 预算与 Bash 白/黑名单正文一律指向对应 persona 文件。想深入任一泳道的调查清单与输出章节要求直接从 personas 目录 的 7 个 persona 文件读起即可。【免费下载链接】GitNexusGitNexus: The Zero-Server Code Intelligence Engine - GitNexus is a client-side knowledge graph creator that runs entirely in your browser. Drop in a git repository (Github, Gitlab, Azure, Local) or ZIP file, and get an interactive knowledge graph with a built in Graph RAG Agent. Perfect for code exploration项目地址: https://gitcode.com/GitHub_Trending/gi/GitNexus创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
