Communitygithub.com

GigleAI/cavil-loop

异步编码代理,由 GitHub 标签驱动 —— 在你睡觉时,你的 AI 并行工作。

cavil-loop 是什么?

这是一个智能体无关的 AI 编码代理工作循环技能,能将 GitHub Issue/PR 评论转化为本地 AI 代理的输入和输出。它通过 systemd 定时器、少量 Shell 脚本和两个 GitHub 标签,允许用户直接在 GitHub Web UI 或 iOS GitHub 应用程序中与 AI 代理进行交互。该技能支持多种代理工作器 CLI,包括 Claude Code(默认)、OpenAI Codex CLI、sst/opencode 和 Cursor Agent CLI,用户可以通过编辑配置文件或编写自定义驱动脚本来切换。其核心价值在于实现了异步并行开发:AI 代理在后台持续处理被标记为“pending/agent”的 Issue 和 PR,而开发者可以专注于其他工作或休息。功能包括一键部署到指定项目、查看代理状态、清理已完成的任务以及禁用某个项目的代理循环,所有状态和日志文件都存储在项目外部,确保主机仓库的整洁。

兼容平台✓Claude Code✓Codex CLI✓Cursor✓OpenCode
npx skills add GigleAI/cavil-loop

在你喜欢的 AI 中提问

打开一个已预加载此 Agent Skill 的新对话。

文档

coding-agent-work-loop

English · 中文

将 GitHub Issue / PR 评论转换为本地 AI 的输入和输出。一个 systemd 定时器 + 少量 Shell 脚本 + 两个 GitHub 标签,让你可以直接通过 GitHub Web UI(或 iOS gh 应用)与 AI 对话。

此技能设计为智能体无关。工作器 CLI 通过在 coding-agent.config 中设置 WORKER_AGENT=<name> 来选择;守护进程/调度脚本通过一个薄的驱动层来接入不同的代理 CLI。内置驱动:claude(默认,Claude Code)、opencode(sst/opencode)、codex(OpenAI Codex CLI)、cursor(Cursor Agent CLI)。通过 scripts/drivers/<name>.sh 添加你自己的驱动——参见 docs/drivers.md.

何时调用

用户通过 /coding-agent-work-loop <command> 或自然语言请求从宿主代理运行时调用此技能。常见形式:

  • "在项目 X 上安装此守护进程" → 运行 setup 流程
  • "编码代理的状态是什么?" → 运行 status 流程
  • "在项目 X 上禁用编码代理" → 运行 disable 流程

你(代理)在被调用时应做什么

setup(部署到宿主项目)

用户给你一个宿主项目路径(例如 ~/github/myproject)。步骤:

  1. 验证路径存在并且是一个 git 仓库(有 .git)
  2. 检查依赖项:git、gh(必须通过 gh auth login 登录)、tmux、jq、flock、systemctl,以及由 WORKER_AGENT 选择的工作器 CLI(默认为 claude;其他内置项:opencode、codex、cursor)。每个都必须能通过 command -v 找到。
  3. 运行:
    bash "${CLAUDE_PLUGIN_ROOT:-$HOME/.agents/skills/coding-agent-work-loop}/setup.sh" <host-project-path>
    
    $CLAUDE_PLUGIN_ROOT 是 Claude Code 注入的技能根目录环境变量;如果不存在,则回退到规范路径 ~/.agents/skills/coding-agent-work-loop。
  4. setup.sh 完成后会打印下一步指导——逐字传达给用户。

status

用户想要查看状态。步骤:

  1. systemctl --user list-timers 'coding-agent-poll@*' --no-pager —— 定时器健康状况
  2. systemctl --user list-units 'coding-agent-poll@*.service' --no-pager —— 最近一次执行
  3. 对于每个已注册的 ~/.config/coding-agent-work-loop/*.conf:
    • tail -20 $STATE_DIR/poll.log(从 conf 文件中读取 STATE_DIR)
    • gh issue list --repo $REPO --label pending/agent + gh pr list --repo $REPO --label pending/agent
  4. 向用户汇总结果

cleanup(在 PR 被接受/拒绝后)

用户合并了一个 PR,或者想要中止某个 Issue 上的工作。步骤:

  1. 确认 Issue 已完成(PR 已合并或关闭)
  2. 运行:
    bash "$CLAUDE_PLUGIN_ROOT/scripts/cleanup-issue.sh" <issue-number>
    
    可选标志:--force(即使工作器忙碌也清理)、--keep-worktree(仅杀死会话)、--delete-branch(也删除本地分支)

cleanup-issue.sh 的作用:

  • 忙碌检查(默认拒绝,除非使用 --force)
  • 运行项目级别的 CLEANUP_HOOK(在 coding-agent.config 中配置,例如拆除 tailscale 端口、停止开发服务器)
  • 杀死工作器的 tmux 会话
  • 移除工作目录(默认)
  • 可选地移除本地分支

disable

用户想要停止一个项目。步骤:

  1. 确认实例名称(systemctl --user list-timers 'coding-agent-poll@*')
  2. systemctl --user disable --now coding-agent-poll@<key>.timer
  3. 可选:删除 ~/.config/systemd/user/coding-agent-poll@<key>.{service,timer} 实例符号链接(保留原始模板不变)
  4. 可选:删除 ~/.config/coding-agent-work-loop/<key>.conf
  5. 报告结果

不会落地到宿主项目中的内容

setup 之后,宿主项目的工作目录只会获得两样东西:

  1. 一行 .gitignore(排除 coding-agent.config)
  2. 一个 coding-agent.config(被 git 忽略,配置文件)

脚本、systemd 单元、状态、日志都位于宿主项目之外(技能目录 + ~/.config/ + ~/.local/state/)。

完整架构

请参见同级 README.md。

文件列表

  • setup.sh — 引导宿主项目
  • scripts/ — 守护进程 + 调度脚本(从不复制到宿主项目)
  • prompts/ — 初始工作器提示模板(可通过宿主项目的 .agents/skills/coding-agent-work-loop/prompts/ 覆盖)
  • systemd/ — [email protected]/.timer 模板单元;setup 会将其复制到 ~/.config/systemd/user/
  • coding-agent.config.example — 配置模板

相关技能