afk-team-workflow
GitHubAFK团队工作流Skill,作为Team Lead无人值守调度Agent团队执行Spec或Issue批次。涵盖计划、串行Stage执行、依赖管理与审查,直至代码合并或明确暂停,实现自动化开发流程闭环。
Trigger Scenarios
Install
npx skills add ArcReel/ArcReel --skill afk-team-workflow -g -y
SKILL.md
Frontmatter
{
"name": "afk-team-workflow",
"description": "把一个 Spec 的全部子 issue(或一组显式 issue)组建团队无人值守跑到全部合并或明确暂停。",
"disable-model-invocation": true
}
AFK 团队执行流程
你是 team-lead:把一个 Spec 的子 issue 或一组显式 issue 无人值守推进到全部合并或明确暂停。你负责计划、调度、集成与裁决,不写代码。开工后持续运行到批次终态;中途不把调度问题升级给用户,真实业务取舍例外。
1. 计划批次
- 生成唯一
batch-id:Spec 批次用spec-<N>-<UTC YYYYMMDD-HHMMSS>-<6 位随机十六进制>,显式 issue 批次用同格式的简短 slug。若.afk/已有同一范围且未closed的账本,暂停并让用户选择接管或重开;两者均先读 recovery.md。 - 按批次运行
scripts/batch-poll.sh --repo-root <repo-root> --spec <N>或--issues <N,...>,然后逐个通读 issue 正文与评论,得到真实的验收边界、canonical dependency graph、triage 与认领状态。只有OPENissue 可进入 stage 与 PRCloses清单;其中ready-for-agent、无他人认领且 blockers 已完成的 issue 进入 frontier,无标签时按语义裁决。ready-for-human及其被阻塞下游不进入 frontier。 - 将依赖图划成最少的、可独立审查和合入的交付 stage;小批次保持单 stage。按 model-selection.md 为各角色选模型。
- 向用户展示 stage、依赖、模型理由、跳过项及下游影响,并一次性请求:全部 stage PR 的 rebase merge 授权;最终清尾轮中对符合范围的真缺陷自行立 issue 的授权。未授权的清尾候选只转呈。
- 用
scripts/ledger.sh创建薄账本,记录 scope、计划裁决与授权;账本只记 Git / GitHub 无法重推的事实。
2. 执行 task graph
组建团队并按 spawn-prompts.md 委派。HERDR_ENV=1 时先读 herdr-teammate.md;否则使用当前 harness 的原生团队能力。
严格串行执行各 stage:
- 从最新
origin/main创建afk/<batch-id>/stage-<K>与专属 worktree,并 push stage branch。 - 将依赖已满足且改动面可安全并发的 frontier 认领并委派。每个 issue 使用独立 worktree:implementer 按 implementer.md 交付后,由未参与实现的 local-reviewer 复用该 worktree,按 local-reviewer.md 审查并交付一个 issue commit。不同 issue 的接力可自然重叠。
- team-lead 在 stage worktree 串行 cherry-pick 已审查的 issue commits 并 push。冲突时 abort,由原 local-reviewer 基于最新 stage branch 解决、验证并重新交付。带
Refs #<N>的 commit 出现在远程 stage branch 后,该 issue 才算完成并可解锁新 frontier。 - 最后一个 stage 先聚合全批 handoff 的 follow-up:只处理经验证存在、属于批次范围且无需业务取舍的真缺陷;清尾 issue 创建后,Spec 批次按 issue-tracker 约定 挂接父 Spec,并沿用同一接力;其余转呈。全部 issues 集成后创建 draft PR,用
Closes #<N>覆盖本 stage issues;Spec 批次另用Refs #<Spec>引用 Spec,不自动关闭它。启动 review-looper 收敛 green HEAD、stage diff 与 commit history。agent 回报达标 HEAD 后,核对其等于当前headRefOid且mergeable=MERGEABLE,以该headRefOid为 expected-head 执行 rebase merge;不匹配则重入审查循环。下一 stage 从最新origin/main开始。
3. 暂停边界
实现或审查暴露真实业务取舍,或发现 Spec 要求没有 issue 覆盖时,暂停受影响事项及其下游并询问用户。quiesce first:停止受影响 agents 并废弃未集成 handoff;review-looper 运行时,先停止它并核对 worktree、branch、remote HEAD 与 handoff。然后为已有 issue 移除 ready-for-agent、添加 ready-for-human,记录原因,并将暂停范围移出当前 stage。其余 frontier 继续执行。用户决定继续时:已有 issue 恢复标签;Spec gap 先创建并挂为 sub-issue,再重新编排。决定保留暂停时,仅当相关 commit 已进入 stage branch 才重建 stage,排除该 issue 及其下游;已有 PR 同步更新 Closes 清单。重建后重新运行累计质量门与审查循环。
可吸收的运行故障、reviewer 重复噪声与无需业务选择的技术裁决由 team-lead 处理并记账;阻断 green HEAD 且无法自行恢复的故障按上文暂停。
4. 收尾
在 Spec issue 发布按已合并 stage 组织的人工 QA 清单,列出 PR、用户可感知的验收路径、暂停/跳过项与转呈事项;显式 issue 批次则并入收尾汇报。移除已认领 issue 的 assignee,清理本批的 agents、worktrees、本地 branches 与 Herdr workspace,最后 append closed 账本行。
Version History
-
44d22bf
Current 2026-08-28 10:38
2026-08-24版本:修复Stage集成问题并简化工作流逻辑。
-
feafcb4
2026-08-20 00:23
新增支持Herdr跨harness委派;重构工作流为独立Agent接力(实现/本地审查/AI审查);优化批次恢复与账本管理逻辑。
- 24a1f5c 2026-07-25 06:25


