概述
fork-manager 是一款面向活跃开源贡献者的专业级 Fork 管理技能，旨在解决"维护多个待合并PR的同时保持与上游同步"这一典型痛点。该工具通过结构化配置和自动化工作流，将原本繁琐的手动Git操作转化为可审计、可恢复的系统化流程。
核心用法
技能采用主代理+子代理的分层架构：主代理（orchestrator）负责任务调度与监控，子代理（worker）执行具体操作。支持以下命令模式：
- status: 快速查看Fork状态——上游落后提交数、各PR分支健康度
- sync: 将主分支同步到上游最新
- rebase/rebase-all: 单个或批量变基PR分支
- build-production: 构建包含所有开放PR和本地补丁的集成分支
- full-sync: 完整同步流程——包含状态检测、配置更新、关闭PR审查、开放PR审计、自动变基、冲突解决（可选）及生产分支重建
- review-closed/review-patches/audit-open: 交互式审查工作流
关键创新在于`--auto-resolve`模式：当检测到变基冲突时，自动派生最多5个并行子代理（Claude Opus模型，10分钟超时），尝试自动解决冲突。冲突被分类为：
- trivial（机械冲突，如导入调整、格式化、文件删除）→ 自动解决并推送
- semantic（业务逻辑冲突）→ 自动解决但标记需人工复核
- unresolvable → 保留冲突状态上报
显著优点
1. 配置即代码: 每个仓库的config.json完整记录开放PR、分支映射、本地补丁及元数据，实现Fork状态的可审计和可迁移
2. 本地补丁一等公民: 独特支持"被拒绝但仍需维护"的代码补丁，通过localPatches结构化管理，含审阅日期提醒机制
3. 韧性设计: 子代理架构隔离上下文消耗；失败自动检测（4分钟轮询）与最多2次重试；操作前自动stash保护未提交文件
4. 智能工作流: full-sync的12步流程科学编排——先处理 reopened PR 恢复，再审查 genuinely closed，最后审计冗余，避免状态竞争
5. 冲突持久化追踪: 通过notes.conflictBranches记录冲突次数，3次以上升级为"持久冲突"专项提示
潜在局限与风险
| 局限 | 说明 |
|------|------|
| **模型依赖** | 自动冲突解决依赖Claude Opus的智能，对复杂架构重构可能误判 |
| **GitHub锁定** | 深度依赖`gh` CLI，暂不支持GitLab/Bitbucket |
| **非原子操作** | 长时间`full-sync`中途失败需依赖checkpoint恢复，非真正事务性 |
| **并发限制** | 5个并行解析器上限，超大型Fork（50+ PRs）可能超时 |
| **语义冲突盲推** | 自动解决的semantic冲突虽有标记，但若用户忽略复核，可能引入隐蔽bug |
适合人群
- 活跃维护者: 同时维护5+开放PR的长期贡献者
- 企业Fork用户: 需要"上游未合并补丁+自有定制"混合代码库的团队
- 多Repo贡献者: 通过统一配置管理多个Fork项目
- 自动化爱好者: 可配合cron实现定时同步（支持紧凑输出模式）
常规风险
- force-with-lease仍有风险: 虽比
--force安全，但若团队其他成员强制推送，仍可能覆盖 - 生产分支非主干:
main-with-all-prs类分支若被误部署，可能引入未经充分测试的PR代码 - 子代理超时残留: 10分钟超时后子代理被kill，但Git仓库可能处于变基中间状态，需手动
git rebase --abort恢复 - 本地补丁审阅疲劳: 默认30天审阅周期，积累过多本地补丁后，每次
full-sync的交互式审阅负担加重
安全评估
技能设计时已内置多重保护：--force-with-lease替代裸--force、操作前强制stash --include-untracked、子代理隔离执行。但本质上仍授予AI代理对目标仓库的写权限（push） 和破坏性操作（branch删除、强制变基），建议在专用CI环境或本地隔离副本中运行，避免直接操作生产关键Fork。