用途
该技能面向单个开源项目维护者，帮助其决定愿意承担多少工作量，并使该决定落地：更轻量、共享或终止，同时通知用户且不将项目错误地交给他人。核心关注点是维护者本身，而非项目。根据 Tidelift 调查，58-60% 的维护者曾退出或考虑退出项目，因此应将过载视为基准率。两个常见原因：过载（流入乘以隐性期望超过可用时间，且无公开契约）和生活变化（首要退出原因）。两者均需通过公开契约、缩小维护面和计划性退出解决。
主要能力
- 访谈与诊断：最多六个问题（目的地、时间预算、主要消耗、人员、用户、时间与资金），可结合仓库只读访问推断信息。
- 量化负载：构建单屏账本，包括流入量、积压分类、当前耗时与预算、过渡耗时、权限集中度。
- 排序举措：按每小时的回报效率排序八项举措（发布契约、声明维护层级、控制输入、自动化杂务、宣布暂停、重置积压、招募共同维护者、资金），默认取前三项，再考虑共享或退出。
- 共享维护：从已有贡献者中招募，明确角色，快速授予分诊和审查权限、缓慢授予合并和发布权限，警惕急于获取权限的请求。
- 妥善退出：根据用户价值、维护者投入、供应链风险、未修补漏洞风险等维度选择交接、托管、冻结后归档或立即归档；提供公告模板、注册表弃用信号、账户与凭证计划、通知期建议。
- 输出计划：生成结构化的可持续性计划（目的地、账本、举措、契约、人员、退出、审查），并逐节验证。
- 健康检查：自设基线，包括预算保持、契约遵守、无单一密钥持有者、结束状态书面化、安全路径明确。
使用方式
通过技能触发后，AI 会先尝试读取仓库信息（如 README、issue/PR 数量、发布历史、贡献者图、合并与发布权限），若无法访问则要求用户提供估算。然后逐一提问（尽量多选），根据答案重新排序举措。例如：硬性日期会提升一天内能落地的举措；主要消耗是敌意评论则优先审核；雇主支付维护者则建议向经理申请增加维护者或缩小范围。最终输出一份计划，并在关键节点（如四周后）回顾账本。
适用场景
- 个人维护者感到过载或考虑退出。
- 希望减少维护时间但保留项目。
- 计划将项目交给他人或组织。
- 需要制定公开的维护契约和响应窗口。
- 需要安全地归档项目而不遗留用户。
限制
- 该技能不替代专业法律或心理健康支持；若用户描述危机而非过载，应建议寻求人际支持，并将计划缩减为最小安全步骤（如发布暂停）。
- 所有数据和案例引用需参考
references/published-findings.md；技能自身基线为自设。 - 不涉及具体代码修改或技术实现，仅提供流程和决策支持。
- 资金举措不能减少流入量，且捐款很少能达到工资水平（如 core-js 作者报告每月约 400 美元）。
- 技能不提供 HTML 输出或收录来源信息。