Greenkeeper

Most weeks on busy repos, the slow part is not the feature work. It is rebasing the same branch for the third time, re-reading the same failing CI log, and clearing the same review thread because a bot left a nit that is easy to dismiss but annoying to track. None of that is intellectually hard. It is just context switching and repetition, and it does not get smaller when you have more PRs in flight.

Greenkeeper is a small Go CLI that tries to automate that loop on hardware you already own. One binary, configuration under ~/.config, and whatever gh is already logged into. It is deliberately not a hosted service: if you want an autopilot in someone else's cloud, this is the wrong tool.

What a tick looks like

The daemon wakes on an interval and walks a watchlist of PR numbers. For each one it asks GitHub for the things humans re-open the tab to check: is it mergeable, which checks are red, which review threads are still unresolved. That snapshot is compared to the rules you configured — for example, "only wake up for CI failures" or "also chase unresolved human comments."

When a PR qualifies, Greenkeeper creates or reuses a git worktree so your primary checkout never picks up half-resolved state. It assembles a prompt that includes your commit and branch naming preferences, the failure or thread text, and enough repo context for an agent to be useful. Then it execs your provider CLI — today that is claude, codex, or a generic shell template with placeholders — and waits for the process to exit.

Afterwards it looks at GitHub again. If the branch is clean, the PR drops off the mental stack and the worktree can go away. If not, it stays in rotation until you unwatch it or the problem is genuinely gone.

After the session: commit, push (typically --force-with-lease after a rebase), then the next poll decides whether the PR still needs work.

Conflicts, CI, and review noise

The README spells out three concrete cases, because those are the ones that ate my calendar before I automated them.

Merge conflicts show up as mergeable == CONFLICTING from GitHub's point of view. The strategy is boring on purpose: rebase onto the base branch, resolve, and push with --force-with-lease so you are not clobbering a colleague's work if the remote moved.

CI failures pull log context into the prompt so the agent is not guessing in a vacuum. Review threads — bot or human — get triaged in the prompt: fix what is real, reply or resolve what is not, and push small commits rather than rewriting published history with blind --force.

Throughout, the tool never merges for you. It fixes branches. You still read the diff and press merge when you are happy. That boundary matters when automation can push.

Why local, why subprocess providers

Running locally means outbound traffic is whatever gh and your provider CLI already send. There is no separate telemetry channel in the binary beyond what those tools do. Pluggable providers are subprocesses rather than compiled-in SDKs so you can swap vendors without recompiling Greenkeeper itself — the integration surface is argv and env, which is ugly but obvious.

Configuration is global TOML under ~/.config/greenkeeper/config.toml, with optional per-repo overrides for things like concurrency and which provider to prefer. There is intentionally no project-local dotfile: the point is a personal machine daemon, not a repo policy hook everyone has to adopt.

Safety rails that survived design arguments

A few decisions are worth calling out because they are the ones I would look for before trusting a tool that can push.

Session runtime is capped so a runaway agent does not hold a worktree forever. Pushes after rebases use lease semantics. The prompts aim at the surfaced failure or review text rather than inviting drive-by refactors across the tree — not perfect, but it nudges the model toward scoped work.

If you try it, do what you would with any power tool: read SPEC.md in the repo, start on a low-stakes branch, and keep an eye on the first few sessions until the defaults match how you work.

Install and links

• Source and full behaviour: github.com/RussellBloxwich/greenkeeper
• Homebrew: brew install RussellBloxwich/tap/greenkeeper
• From source: go install github.com/russellbloxwich/greenkeeper/cmd/greenkeeper@latest (see the repo for supported Go versions)

License: MIT.