核心功能与工作流程
1. 智能检索与分类（Triage）
-
优先使用本地缓存：首先通过
gitcrawl命令在本地归档中检索相关的线程、重复 Issue 和已修复的补丁，以提高效率并减少 API 调用。 -
候选者筛选：在筛选可处理的 Issue 时，会自动压制（Suppress） 由核心维护者（如
@vincentkoc,@Takhoffman等）在 14 天内创建的 PR，优先处理外部贡献者的 PR。 -
申请具体审查目标：在审查特定 Issue/PR 前，会检查分配状态。如果未分配，会自动分配给请求者；如果已分配给他人，会明确提示并评估分配时长（如 6 小时内视为活跃拥有）。
2. 贡献者身份与活跃度分析
-
自动化档案查询：对于每一个被审查的 Issue/PR，技能会自动提取并报告提交者的姓名、GitHub ID、账号年龄以及过往贡献。
-
双轨活跃度报告：会以一行紧凑的信息展示贡献者在 OpenClaw 项目内（过去12个月的 PR、Issue、Commits）和 GitHub 全局的活跃度，作为分类（Triage）的信号之一。
3. 严格的 PR 审查流程
-
首先理解变更：审查开始前，必须用1-3句平实的语言解释 PR 做了什么以及为什么重要。
-
审查周边代码：不仅审查变更的行，还必须阅读调用方、被调用方、数据契约和相邻测试，理解完整的运行时边界。
-
“最佳修复”评判：明确回答“这是最佳修复，还是仅仅是一个可行的修复？”在给出结论前，必须考虑至少一个替代方案并解释为何拒绝。
-
溯源（Provenance）：对于 Bug 修复，必须通过
git blame等工具定位引入问题的责任方，并区分代码作者、PR 作者、PR 合并者等不同角色。
4. 合并（Landing）与关闭（Closing）的严格标准
-
证据驱动的合并：绝不仅凭 Issue 或 PR 的文字描述合并一个 Bug 修复。必须提供可复现的证据（如复现步骤、日志、失败的测试），并且修复必须触及问题代码路径。
-
优先使用 Crabbox：在可能的情况下，优先使用
$crabbox进行端到端（E2E）验证，而不是仅依赖单元测试。 -
谨慎关闭低质量 PR：明确列出了可以关闭的 PR 类型（如空白 PR、随机文档改动、测试覆盖率改动、第三方插件工作等），但对于聚焦的 Bug 修复和活跃的讨论则保留或升级。
-
安全的文本处理：在处理 Issue/PR 评论时，要求使用字面多行字符串或 heredoc，避免因特殊字符（如反引号）导致 Shell 命令执行错误。
5. 审查输出规范
-
结构化输出：每次 PR 审查的输出必须包含 Findings（发现）、LOC（代码行数变更）、Best-fix verdict（最佳修复 verdict）、Alternatives considered（考虑的替代方案）、Code read（阅读的代码文件）以及 Remaining uncertainty（剩余的不确定性）。
-
禁止提及发布说明：在审查输出中，绝不提及 Changelog 等发布说明的记账工作，这属于发布流程而非审查范畴。
主要用途
-
维护者日常分类（Triage）：快速从大量 Issue/PR 中筛选出高价值、可处理的外部贡献，并自动化身份验证和分配工作。
-
深度代码审查：强制要求审查者理解代码的完整上下文和运行时行为，而不仅仅是 diff，从而做出“是否是最佳修复”的专业判断。
-
自动化合并与关闭：为合并和关闭操作提供一套基于证据的、标准化的门槛，减少人为误判，确保代码库质量。
-
责任溯源：在引入 Bug 时，能够清晰地追溯到引入该问题的具体 PR、作者和合并者，帮助团队复盘。
总结
OpenClaw PR Maintainer 是一个为 OpenClaw 核心维护者设计的、高度自动化和规范化的 GitHub 工作流管理技能。它将项目维护的最佳实践（如优先处理外部贡献、强制证据驱动的合并、深度代码审查）固化为可执行的流程，旨在提升大型开源项目的管理效率和质量控制水平。
