什么是 Fork 管理器？

Fork 管理器是一款专业级工具，专为在向上游仓库贡献代码时维护活跃 fork 的开发者设计。通过利用 Openclaw Skills 框架，该智能体可以自动执行与上游远程库同步、同时变基多个 PR 分支以及跟踪待处理贡献状态的复杂过程。它确保您的本地开发环境与上游更改保持同步，且不会丢失您独特的改进或本地补丁。

该技能运行在弹性编排器和工作器模型上，能够轻松管理高吞吐量的代码库。它通过提供一种结构化的方式来处理 PR 生命周期（从初始创建到自动冲突解决），有效减少了 Git 维护的手动开销。对于任何希望在 Openclaw Skills 生态系统中扩展其贡献工作流的开发者来说，这都是一个必不可少的组件。

下载入口:https://github.com/openclaw/skills/tree/main/skills/glucksberg/fork-manager

安装与下载

1. ClawHub CLI

从源直接安装技能的最快方式。

2. 手动安装

将技能文件夹复制到以下位置之一

优先级：工作区 > 本地 > 内置

3. 提示词安装

将此提示词复制到 OpenClaw 即可自动安装。

Fork 管理器 应用场景

• 将 fork 与上游仓库同步，以保持与最新提交同步。
• 自动将所有打开的拉取请求（PR）分支变基到最新的上游主分支。
• 构建并维护一个整合的生产分支，结合多个打开的 PR 和本地补丁。
• 审计打开的 PR，以检测上游维护者是否已经解决的冗余或更改。
• 管理针对被上游仓库拒绝或取代的关键修复的本地补丁。

1. 智能体通过从特定的 Openclaw Skills 目录加载仓库配置和执行历史记录来进行初始化。
2. 它从上游和源远程库执行深度获取（fetch），以评估所有分支的同步状态。
3. 使用 GitHub CLI 验证拉取请求状态，以识别已合并、已关闭或过时的贡献。
4. 编排器派生工作智能体来执行同步和变基操作，确保主智能体的上下文窗口保持整洁。
5. 如果出现合并冲突，系统可以启动专门的 AI 子智能体，利用语义逻辑解决冲突。
6. 生成一份全面的状态报告并附加到历史日志中，并重建生产分支以包含所有已验证的更改。

Fork 管理器 配置指南

要开始使用 Fork 管理器，请确保您已安装 Git 和 GitHub CLI 并完成身份验证。在 Openclaw Skills 结构中为您的仓库创建一个配置文件：

# 确保依赖项可用
git --version
gh --version

# 设置配置目录
mkdir -p fork-manager/repos/your-project-name
touch fork-manager/repos/your-project-name/config.json

在 config.json 中填充您的仓库元数据，包括 localPath、upstreamRemote 和 prBranches，以便智能体跟踪您的工作。

Fork 管理器 数据架构与分类体系

该技能通过 Openclaw Skills 内的结构化文件系统维护状态和元数据。这确保了透明度以及从中断中轻松恢复。

name: fork-manager
description: Manage forks with open PRs - sync upstream, rebase branches, track PR status, and maintain production branches with pending contributions. Supports automatic conflict resolution via --auto-resolve flag (spawns AI subagents to resolve rebase conflicts). Use when syncing forks, rebasing PR branches, building production branches that combine all open PRs, reviewing closed/rejected PRs, or managing local patches kept outside upstream. Requires Git and GitHub CLI (gh).
metadata: {"openclaw": {"requires": {"bins": ["git", "gh"]}}}

Fork Manager Skill

Manage forks where you contribute PRs but also use improvements before they're merged upstream. Includes support for local patches — fixes kept in the production branch even when the upstream PR was closed/rejected.

When to use

• Sync a fork with upstream
• Check status of open PRs
• Rebase PR branches onto latest upstream
• Build a production branch combining all open PRs + local patches
• Review recently closed/rejected PRs and decide whether to keep locally
• Manage local patches (fixes not submitted or rejected upstream)

When NOT to use

• General GitHub queries (issues, PRs, CI status on any repo) → use github skill instead
• Triaging/ranking/prioritizing issues → use issue-prioritizer skill instead
• Reviewing code changes before publishing a PR → use pr-review skill instead
• Creating new PRs from scratch (not fork sync) → use gh pr create directly

Execution Model — Orchestrator + Worker

A skill NUNCA deve ser executada inline pelo agente principal. Sempre usar o padr?o orchestrator/worker:

Fluxo

1. Orchestrator (agente principal) — prepara o contexto e spawna um subagente:

   sessions_spawn(
     task: "",
     model: "",
     mode: "run"
   )
   

2. Worker (subagente) — executa o full-sync/status/rebase/etc. Lê a SKILL.md, segue o fluxo, escreve history.
3. Monitoramento — o orchestrator checa progresso a cada 4 minutos via sessions_list / sessions_history:
   • Se o worker estiver ativo e progredindo → aguarda
   • Se o worker estiver parado/travado (sem output novo por 2 checks consecutivos) → subagents kill + spawna novo worker
   • Se o worker completou → lê o resultado e reporta ao usuário
4. Fallback — se o worker falhar (crash, timeout, erro):
   • Orchestrator verifica o estado do repo (git status, último checkpoint)
   • Spawna novo worker com contexto atualizado incluindo o ponto onde parou
   • Máximo de 2 retries antes de reportar falha ao usuário

Contexto para o Worker

O orchestrator deve incluir no prompt do worker:

• Path da SKILL.md (para o worker ler e seguir)
• Config do repo (inline ou path)
• última entrada do history (resumo ou path)
• Modo de execu??o (full-sync, status, rebase-all, etc.)
• Se é cron mode ou manual
• Quaisquer instru??es específicas do usuário

Por que subagente?

• Resiliência: se o worker falha, o orchestrator pode recuperar
• Context window: a skill é pesada (145+ PRs = muito output). O worker gasta seu context sem poluir o agente principal
• Paralelismo futuro: permite spawnar workers para repos diferentes simultaneamente

Cron Mode

When invoked by a cron job (automated recurring sync), follow these guidelines for efficient execution:

1. Skip interactive prompts — auto-resolve decisions that don't require human input:
   • Rebases: attempt automatically, report failures
   • Closed PRs: report but defer decision (don't drop or keep without human input)
   • Audit findings: report but don't act
2. Compact output — use the summary format, not full verbose report:

   ?? Fork Sync Complete — 
   Main: synced N commits (old_sha → new_sha)
   PRs: X open, Y changed state
   - Rebased: A/B clean (C conflicts)
   Production: rebuilt clean | N conflicts
   Notable upstream: [1-3 bullet highlights]
   

3. Checkpoint on failure — if a rebase fails or production build has conflicts, write state to repos//checkpoint.json so the next run (or manual invocation) can resume
4. Time budget — target <10 minutes total. If rebasing 20+ PRs, batch push at the end instead of per-branch

Configuration

Configs are organized per repository in repos//config.json relative to the skill directory:

fork-manager/
├── SKILL.md
└── repos/
    ├── project-a/
    │   └── config.json
    └── project-b/
        └── config.json

Formato do config.json:

{
  "repo": "owner/repo",
  "fork": "your-user/repo",
  "localPath": "/path/to/local/clone",
  "mainBranch": "main",
  "productionBranch": "main-with-all-prs",
  "upstreamRemote": "upstream",
  "forkRemote": "origin",
  "autoResolveConflicts": false,
  "openPRs": [123, 456],
  "prBranches": {
    "123": "fix/issue-123",
    "456": "feat/feature-456"
  },
  "localPatches": {
    "local/my-custom-fix": {
      "description": "Breve descri??o do que o patch faz",
      "originalPR": 789,
      "closedReason": "rejected|superseded|duplicate|wontfix",
      "keepReason": "Motivo pelo qual mantemos localmente",
      "addedAt": "2026-02-07T00:00:00Z",
      "reviewDate": "2026-03-07T00:00:00Z"
    }
  },
  "lastSync": "2026-01-28T12:00:00Z",
  "notes": {
    "mergedUpstream": {},
    "closedWithoutMerge": {},
    "droppedPatches": {}
  }
}

Resolu??o automática de conflitos (autoResolveConflicts)

A resolu??o automática pode ser ativada de duas formas (qualquer uma basta):

1. Flag de invoca??o (ad-hoc, por execu??o):

   /fork-manager --auto-resolve
   /fork-manager full-sync --auto-resolve
   

2. Config persistente (sempre ativo pra aquele repo):

   { "autoResolveConflicts": true }
   

Precedência: --auto-resolve na invoca??o ativa a resolu??o mesmo se o config diz false. N?o existe --no-auto-resolve — se o config diz true e o usuário n?o quer resolver, basta n?o rodar o passo manualmente.

Para usuários do ClawHub: basta passar --auto-resolve no comando. Nenhuma configura??o de repo necessária.

Campos de localPatches

Cada entry em localPatches é uma branch local mantida na production branch mas sem PR aberto no upstream.

Histórico de Execu??es

Cada repositório gerenciado tem um arquivo history.md que registra todas as execu??es da skill como um livro de registro append-only:

fork-manager/
└── repos/
    ├── project-a/
    │   ├── config.json
    │   └── history.md
    └── project-b/
        ├── config.json
        └── history.md

Regra: Ler último output antes de come?ar

Antes de qualquer opera??o, ler o history.md do repositório alvo e extrair a última entrada (último bloco ---). Isso dá contexto sobre:

• O que foi feito na última execu??o
• Quais PRs tinham problemas
• Quais decis?es foram tomadas
• Se ficou alguma a??o pendente

# Ler última entrada do history (tudo após o último "---")
tail -n +$(grep -n '^---$' "$SKILL_DIR/repos//history.md" | tail -1 | cut -d: -f1) "$SKILL_DIR/repos//history.md"

Se o arquivo n?o existir, criar com o header e prosseguir normalmente.

Regra: Registrar output ao finalizar

Ao final de toda execu??o, fazer append ao history.md com o resultado completo. Formato:

---
## YYYY-MM-DD HH:MM UTC | 
**Operator:** 

### Summary
- Main: 
- PRs: 
- Local Patches: 
- Production: 

### Actions Taken
- 
- <"Rebased 21/21 branches clean">
- <"PR #999 closed → kept as local patch local/my-fix">
- <"PR #777 reopened → restored to openPRs (was in droppedPatches)">

### Pending
- 
- <"3 local patches with expired reviewDate — run review-patches">

### Full Report

Importante: O bloco Full Report contém o relatório completo sem abrevia??o. Isso garante que o próximo agente que ler o history tenha toda a informa??o, n?o apenas o resumo.

Fluxo de Análise

1. Carregar config e histórico

Resolve the skill directory (where SKILL.md lives):

# SKILL_DIR is the directory containing this SKILL.md
# Resolve it relative to the agent's workspace or skill install path
SKILL_DIR=""

# Load config for the target repo
cat "$SKILL_DIR/repos//config.json"

# Ler último output do history para contexto
HISTORY="$SKILL_DIR/repos//history.md"
if [ -f "$HISTORY" ]; then
  # Extrair última entrada (após último ---)
  LAST_SEP=$(grep -n '^---$' "$HISTORY" | tail -1 | cut -d: -f1)
  if [ -n "$LAST_SEP" ]; then
    tail -n +"$LAST_SEP" "$HISTORY"
  fi
fi

2. Navegar para o repositório

cd 

3. Fetch de ambos remotes

git fetch 
git fetch 

4. Analisar estado do main

# Commits que upstream tem e origin/main n?o tem
git log --oneline /../

# Contar commits atrás
git rev-list --count /../

5. Verificar PRs abertos via GitHub CLI

# Listar PRs abertos do usuário
gh pr list --state open --author @me --json number,title,headRefName,state

# Verificar status de um PR específico
gh pr view  --json state,mergedAt,closedAt,title

6. Classificar cada PR

Para cada PR no config, verificar:

Comando para verificar se branch precisa rebase:

git log --oneline /../ | wc -l  # commits à frente
git log --oneline /../ | wc -l  # commits atrás

7. Revisar PRs recém-fechados (review-closed)

Quando um PR é detectado como fechado sem merge, N?O remover automaticamente. Iniciar um fluxo de revis?o interativo:

7.1. Coletar contexto do fechamento

# Buscar comentários e motivo do fechamento
gh pr view  --repo  --json title,closedAt,state,comments,labels

# Verificar se upstream resolveu o problema de outra forma
# (procurar PRs mergeados recentes que toquem os mesmos arquivos)
gh pr list --state merged --repo  --json number,title,mergedAt --limit 30

7.2. Classificar o motivo do fechamento

7.3. Apresentar ao usuário para decis?o

Para cada PR fechado, apresentar:

### PR # —