GitHub Open portal
Rookery

Label the issue.
Approve the plan.
Review the pull request.

Rookery watches your repositories for one label. It reads the issue, writes a plan you sign off on, then works the task list one task at a time and opens a draft pull request. It never merges. That part is still yours.

Open portal See the loop

stdlib python · gh + claude on PATH · no database

sa-es-ir/rookery#3

Create the frontend portal

Operator-facing pages for the orchestrator: the agent roster, the workflow canvas, and a run view that reads its state from the issue labels. Dark theme, no build step, no framework.

opened by sa-es-ir · 4 tasks planned
  • ✓Scaffold the portal shell
  • ✓Render agents from state
  • ✓Build the workflow canvas
  • ✓Wire the run sequence
agent-plans/3/tasks.mdfeature/issue-3
The loop

Six labels, one of them yours

State lives on GitHub, not in a database here. The labels on the issue are the state machine — you can read where a run stands without opening anything else, and you can stop it by removing a label.

  1. rookery:trigger

    You start it

    Nothing runs until someone puts the label on. There is no polling and no autonomous pickup.

    requires you
  2. rookery:planning

    planmaker reads the repo

    It writes plan.md, tasks.md and decisions.md into the target repo and touches nothing else.

  3. rookery:awaiting-input

    It asks when it has to

    An open question comes back as an issue comment. Reply and planning resumes in the same session with your answer folded in.

  4. rookery:awaiting-approval

    You approve it

    The plan is posted for review. Comment approve to start the work — matched as text, from a login on your allowlist.

    requires you
  5. rookery:implementing

    One task, then the next

    A fresh session per task. Rookery ticks the checkbox, commits, and moves on. Fifteen tasks is the ceiling; the loop stops rather than wandering.

  6. rookery:reviewing

    A second agent reads the diff

    Advisory, and it runs once. The branch is pushed and the draft PR opened either way, so work is never stranded on someone's laptop.

Guarantees

Properties, not settings

These are structural. There is no configuration flag that turns them off, because each one is what keeps a long run predictable.

Cost

Issue 300 costs what issue 3 did

Every task gets its own session, so context never snowballs across a long issue. decisions.md is the only thing that crosses between tasks.

Authorship

Rookery commits, the agent doesn't

Task sessions run with git push and gh denied outright. The orchestrator ticks the checkbox and writes the commit, so history stays legible.

Approval

Your approval is read, not judged

The word is matched against a pattern and the author against your allowlist. No model decides whether you meant yes, and the bot is filtered out so it can't approve itself.

Review

The plan ships inside the PR

Plan, tasks and decisions are committed to the branch. A reviewer sees what was intended next to what was written, in one place.

Isolation

One worktree per issue

Each issue gets its own branch and its own checkout, so two repositories can share an issue number and never meet.

Throughput

One job at a time, on purpose

A single worker drains the queue. A long implementation blocks the others — a deliberate trade for a machine you can reason about.

What it won't do

The short list

neverPush to your base branch

Checked before every push. Branch protection is the backstop, not the guard.

neverMerge anything

The output is a draft pull request. A human merges, every time.

neverAct on an unsigned webhook

The signature is verified first, and repositories you haven't configured are dropped.

neverGuess at a result

A task reports its status as a literal marker. A missing one is an error, not an assumption.

Point it at a repository

Configure the repos you want covered, invite the agents you trust, and watch the queue from one place.

Open portal