# Maintainer Playbooks

Playbook 是把 Evidence Pack 转成治理动作的规则库。Agent 应选择 1-3 个最相关剧本。

## P1 低活跃恢复

触发条件：

- [E9] 最近 30 天提交很少或没有提交。
- [E2] open Issue 有新增但缺少回复。
- [E10] 贡献者集中在 1-2 人。

风险信号：

- 项目对外仍有关注、Fork 或 Issue，但维护节奏下降。
- 新贡献者不知道项目是否还接受贡献。

本周动作：

- 回复所有超过 14 天未更新的 open Issue。
- 创建“维护状态说明”Issue，说明当前优先级和可接受贡献范围。
- 标记 2-3 个适合外部贡献者的小任务。

30/60/90 天计划：

- 30 天：清理过期 Issue，保留可复现、可行动的问题。
- 60 天：补 README 的安装、运行、贡献入口。
- 90 天：建立每月一次的维护节奏，发布一个小版本或维护公告。

验收标准：

- open Issue 中超过 14 天未回复的数量减少 70%。
- 至少 3 个 Issue 有明确下一步。
- README 有贡献入口或维护状态说明。

## P2 PR 堵塞清理

触发条件：

- [E4] open PR 数量较多。
- [E4] 存在超过 7 天未更新或未评审的 PR。
- [E5] merged PR 样本少于 open PR 样本。

风险信号：

- 贡献者提交后长期没有反馈。
- PR 无法合并导致贡献热情下降。

本周动作：

- 按“可合并 / 需要修改 / 已过期”三类整理 open PR。
- 对每个超过 7 天未更新的 PR 留下明确反馈。
- 优先合并低风险文档、测试、修复类 PR。

30/60/90 天计划：

- 30 天：把 open PR 降到可管理数量。
- 60 天：建立 PR 模板和评审 SLA。
- 90 天：把常见检查迁移到 CI，减少人工评审负担。

验收标准：

- 所有 open PR 都有最新维护者反馈。
- 超过 14 天未更新的 open PR 数量降到 0 或给出关闭理由。
- 新 PR 平均首次响应时间少于 7 天。

## P3 新人友好改造

触发条件：

- [E12] README 缺少安装、运行、测试、贡献指南中的任意两项。
- [E2] open Issue 缺少标签或优先级。
- [E10] 贡献者数量少，但项目仍有 Issue 或关注。

风险信号：

- 潜在贡献者无法判断从哪里开始。
- Issue 内容对新人不可执行。

本周动作：

- 在 README 补充最短运行路径。
- 给 2-5 个简单 Issue 加上“good first issue”或等价说明。
- 为新人任务补充复现步骤、预期行为和验收标准。

30/60/90 天计划：

- 30 天：补齐 README、CONTRIBUTING 或 Issue 模板。
- 60 天：形成新人任务池。
- 90 天：复盘新人贡献转化，保留有效标签和模板。

验收标准：

- README 包含安装、运行、测试、贡献四个入口。
- 至少 3 个 Issue 可被新人独立领取。
- 新 Issue 模板能引导用户提供复现信息。

## P4 Release 稳定化

触发条件：

- [E7] 没有 Release，或最近 Release 距今较久。
- [E9] 最近提交包含多项功能或修复。
- [E5] 已合并 PR 有明显用户可见变更。

风险信号：

- 用户无法判断可用版本。
- 变更沉淀在提交记录中，没有形成版本说明。

本周动作：

- 生成下一版 Release Notes 草稿。
- 梳理已合并变更为 `Added / Fixed / Changed / Docs`。
- 明确是否需要补充测试或 CI 后再发布。

30/60/90 天计划：

- 30 天：发布一个维护版本或明确下个版本计划。
- 60 天：固定 Release Notes 模板。
- 90 天：把 Release 与里程碑、Issue、PR 建立关联。

验收标准：

- 至少有一个可追溯 Release 或版本计划。
- Release Notes 能关联主要 Issue/PR/Commit。
- 用户能从 README 找到最新稳定版本。

## P5 基础治理补齐

触发条件：

- [E1] `license_name` 为空。
- [E1] description 为空或项目元信息不足。
- [E8] CI 数据缺失或持续失败。
- [E12] README 缺失或内容过短。

风险信号：

- 项目难以被搜索、复用、评审或贡献。
- 比赛/开源收录时材料不完整。

本周动作：

- 补项目描述、License、README 快速开始。
- 确认默认分支和基础 CI 状态。
- 建立一个“项目治理基线”Issue 追踪补齐事项。

30/60/90 天计划：

- 30 天：补齐 README、License、基础元信息。
- 60 天：补 Issue/PR 模板和贡献说明。
- 90 天：形成版本发布、CI、维护响应的固定节奏。

验收标准：

- 仓库详情中项目描述、License、README 均可见。
- CI 至少覆盖构建或测试中的一项。
- 维护者能用一个治理 Issue 跟踪剩余事项。

## 选择规则

- High 风险剧本优先。
- 同类风险只选择一个主剧本，避免输出重复建议。
- 如果数据样本少，优先选择 P5 基础治理补齐。
- 如果用户明确关注新人、Release 或 PR，则用户目标优先于自动排序。
