PABLO

Personal Assistant for Boring Logic & Operations

Your agents got faster.
Your brain didn't.

PABLO watches every pull request, every CI run, every review, and starts the right AI agent in the right worktree when something needs doing. You stop being the human router of your own tasks.

Get started Read the docs →
  • Open source · MIT
  • Linux & macOS
  • GitHub · Jira · Linear
~/work — pablo
$ pablo task:list
branchstatePRagents

The problem

The morning checklist

Five or six open PRs across two or three projects. Every morning, the same round:

  • Is CI green?
  • Has anyone reviewed it?
  • Has QA picked it up?
  • Any feedback on the ticket?
  • CI red? Notice it, open a worktree, pick an agent, launch it, wait…

None of it is hard. That's the problem: each item is a context switch, and I'd spent a year getting rid of those.

One question, on a loop

Given the state of this pull request, is there something an agent should do, and if so, which one?

If there is, PABLO launches it through your agent environment, in the right worktree, exactly the way you would have.

How it works

Ten states, and what wakes them

One task = one branch, one worktree, one state. A background poller checks every PR every few minutes and moves it through a plain state machine. Click a state to see what happens when a task enters it.

PABLO's task state machine in-progress draft ready-to-review waiting-review approved needs-testing waiting pause from (almost) anywhere ci-red request-changes testing-failed /pablo-commit-and-pr
a command you type (pablo task:start, /pablo-commit-and-pr) detected by the poller work comes back to you, with an agent's analysis

A merge closes the task from any state: PABLO deletes its state and removes the worktree. There's no todo state on purpose: a ticket nobody has started has no task yet.

5 min
systemd / launchd wakes PABLO up
10 min
between a red CI at 11 pm and ci-analyst starting in the right worktree
12 h
worktrees rebased onto the primary branch
0 tokens
spent finding out whether there's anything to do

Agents

One state, one agent

The intelligence lives in a handful of markdown agents. The rest is plumbing that decides when to turn the tap on. Each launch has the same shape: a link (ticket or PR), the right worktree, the agent picked by the state. You don't write prompts any more, you read results.

task-analyst

in-progress

Reads the ticket, its parents, linked PRs and the relevant code, then hands you a summary and an action plan. Runs once per task.

ci-analyst

ci-red

Fetches the failing checks and their logs, ties each failure to the code that caused it, and proposes a fix plan.

pr-feedback

request-changes

Turns review comments into a fix plan. The PR goes back to draft on GitHub.

task-feedback

testing-failed

Checks QA feedback against the PR one point at a time, and drafts a reply for the ticket.

rebase-conflict-resolver

sync conflict

The one deliberate exception. When the 12-hour rebase hits a conflict, git aborts cleanly and this agent replays the rebase. It can rewrite your branch, but it can't act as you: no merge, no review, no comment.

The first four are read-only. They analyse and never touch your code. A fast, cheap, low-temperature model is enough for them.

“The dangerous permission was never edit. It was acting as me in front of other people.”

Principles

Agents suggest, you decide

Read-only by construction

Analysis agents can't edit files, can't run anything but read-only git, and can never push. That's enforced in their permissions, not just asked for in the prompt. Even if a ticket says “just fix it quickly”, they can't.

# task-analyst.md (frontmatter)
permissions:
  - { action: edit,  resource: "*",          effect: deny }
  - { action: shell, resource: "*",          effect: deny }
  - { action: shell, resource: "git *",      effect: allow }
  - { action: shell, resource: "git push *", effect: deny }

You decide when a task leaves you

The only way into draft is a command you type: /pablo-commit-and-pr writes the commit and the PR description, then hands the task back to PABLO. Everything after that is the poller's job.

Boring on purpose

Polling, transitions, review triage, “is CI green?”, worktree sync: all of it is deterministic PHP. An LLM only runs when there's something to read, understand or decide.

No tokens stored

PABLO talks to the CLIs you've already logged into: gh, acli, linear, opencode, claude or copilot. pablo system:doctor tells you what's missing before a cron job fails at 3 am.

Careful with git

It never uses --force, only --force-with-lease, so your own push always wins. Dirty branches are never rebased. The primary checkout is only reset when it's clean and has no local commits.

Trackers stay read-only

Jira, GitHub Issues and Linear are only ever read. PABLO changes git branches and PR metadata (draft or ready), never your tickets.

Dashboard

What needs you, at a glance

  • Two tables: tasks waiting on your feedback, and everything that's someone else's turn.
  • A live countdown to the next poll.
  • Ready-to-paste Slack messages for your PRs waiting on review.
  • Token and cost analytics for every agent run.
  • Strictly read-only, served from the poller's cache, so it opens instantly.
$ pablo web   # → http://127.0.0.1:8321
The PABLO web dashboard listing tasks by state

Fits your setup

Sits on top of the tools you already use

Issue trackers

GitHub IssuesJiraLinearConfluence

Code & CI

GitHub PRsGitHub ActionsCircleCIany check

Agents

OpenCodeClaude CodeCopilot CLIOrcaOpenChamberheadless

Scheduler

systemd (Linux)launchd (macOS)

Get started

From clone to first task

1

Install

Puts pablo on your PATH, links the agents and starts the scheduler and the dashboard.

$ git clone https://github.com/Korbeil/pablo
$ cd pablo && ./bin/install.sh
2

Check & configure

The doctor checks every CLI and its auth. The wizard adds your first project.

$ pablo system:doctor
$ pablo project:new
3

Start a task

From an issue link or a plain prompt. The task-analyst starts right away.

$ pablo task:start <issue-url>
> /pablo-commit-and-pr  # in OpenCode, Claude Code or Copilot

You'll need: git, OpenCode, Claude Code or GitHub Copilot CLI, and an agent environment (Orca or OpenChamber), plus PHP 8.4 to run PABLO. Then the command-line tool of each service your projects use: gh for GitHub, acli for Jira, linear for Linear. Quickstart guide →

Articles

The story behind PABLO

Aug 2026 · JoliCode blog The Agent Development Environment: A New Unit of Work Tasks, worktrees and agents instead of files and buffers: the working environment PABLO was built on top of. Sep 2026 · JoliCode blog From an ADE to an Orchestrator: Building PABLO My agents got faster, my brain didn't: why I built PABLO and what's inside it.

Brain time is the resource.

Your agents already do the analysis. PABLO handles the noticing and the waiting.

Get started