Rovara loop on GitHub issues

What Rovara loop is#

rovara loop turns collaborators’ comments on your GitHub issues into work for your own Claude Code or Codex, and drives that work through plan approval, checks, reviews and a pull request. It needs no Rovara install and no AWS account: only the Rovara CLI, the GitHub CLI (gh, signed in), tmux, git, and Claude Code or Codex.

Published native workflow · current source reference

Rovara v0.3.4 includes the native workflow. This page follows the inspected mainline source, which may include later changes. Deployment settings and feature flags still apply. Release and coverage details →

Available today: the Do, Quick, Full, Review and Contribute loops. Webhooks, Slack approvals and Jira come later. The idea is inspired by the-loop by Rohith Ramakrishnan; Rovara loop is Rovara’s own implementation.

Set up a repository#

In a checkout of the repository:

rovara loop init     # writes .rovara/loop.yaml, with you as its one collaborator
git add .rovara/loop.yaml && git commit -m "chore: rovara loop config"
rovara loop add      # lets the loop read this repository's issues
rovara loop start    # runs the daemon in the background

.rovara/loop.yaml says who the loop obeys and how changes are proved:

version: 1
collaborators:      # the only GitHub logins whose comments start, steer or stop a loop
  - maya
  - sam
harness:
  name: claude-code # or codex
  args: []
checks:             # run before a pull request, in order
  - name: tests
    run: npm test
reviews:
  enabled: true
  harness: codex    # a different agent from the one doing the work is a real critic
  security: true
  maxRounds: 3

Comments from anyone else are never read as instructions. A repository is read from the moment it is added; older comments are never replayed.

Choose a loop#

Comment	What it does
`/rovara do <instruction>`	Works on its own branch with no gates. Commits, but never pushes or opens a PR.
`/rovara quick <instruction>`	Plan → approval → code → checks → reviews → pull request.
`/rovara full <instruction>`	Requirements, design and plan, each approved, then as Quick.
`/rovara review [brief]`	Reviews open PRs against a collaborator’s brief. Changes no code.
`/rovara contribute`	Joins an existing issue or someone else’s PR to meet a stated goal and success criteria.

Steer with replies on the issue. /rovara approve passes a gate, /rovara changes: … (or any reply) asks for changes, and /rovara stop or closing the issue ends the loop. The issue’s rovara:* label shows where it stands.

Quick and Full#

Quick: the agent writes docs/rovara/<issue>/plan.md (Summary, Changes, Testing) and changes no code. A collaborator approves it, which locks it. The agent codes, commits and writes a self-review; the loop runs the repository’s checks and reviews. Then the loop itself, never the agent, pushes rovara/<issue> and opens a PR that closes the issue.

Full adds requirements.md and design.md before the plan, each with its own gate. A later claim that changed an approved document is refused. /rovara full --skip design declares a phase away, and the PR says who declared it. Before publishing, the loop commits checks.md and reviews.md to docs/rovara/<issue>/evidence/.

Nothing is pushed before the plan is approved, the checks pass and the reviews pass, or a person accepts them.

Reviews#

The agent’s own review, written to evidence/self-review.md. A claim without it is refused.
A code review and a security review, run headless and read-only: Claude Code in plan mode, or Codex in its read-only sandbox with reviews.harness: codex.
The blocking rule. A finding blocks when the change introduced it; a security finding is never advisory.

A blocking finding goes back to the agent. After maxRounds rounds that still block, or a review that could not run, a person decides. A review that could not run never counts as a pass.

Pull requests and several repositories#

Once the loop opens a PR, collaborators’ comments, inline review comments and change-requesting reviews reach the agent like replies on the issue. The loop reruns checks and reviews and pushes to the same PR. Merging closes the issue, which ends the loop.

When the plan lists a ## Repositories section, the loop starts one per-PR loop for each repository, each with its own agent, worktree, branch, checks and reviews under that repository’s .rovara/loop.yaml. Each PR is approved on itself. When every PR is approved, the issue lists them and waits for you to merge.

Watch and answer the agent#

The agent runs interactively in tmux. tmux attach -t =rovara-<owner>_<repo>-<issue> shows it; detach with Ctrl-b d.

Claude Code starts in its default permission mode and asks before edits or commands. Pass a permission mode in harness.args to change that.
Codex starts in its workspace-write sandbox, without network access.

When the agent has waited on a permission prompt for a minute, the loop says so on the issue. A session that ends while working is resumed up to three times in a row.

Commands#

Command	Does
`rovara loop init [path]`	Writes `.rovara/loop.yaml`.
`rovara loop add [path]` · `remove <owner/name>`	Starts or stops reading a repository’s issues.
`rovara loop start` · `stop` · `status`	Controls the background daemon. Its log is `~/.rovara/loop/daemon.log`.
`rovara loop do` · `quick` · `full --issue <n> <instruction>`	Posts the matching `/rovara` comment on the issue, as you.
`rovara loop review` · `contribute --issue <n> [brief]`	Posts `/rovara review` or `contribute`, as you.
`rovara loop check <issue>`	Shows where an issue’s loop stands without running anything.

What is kept where#

Your computer: each work item’s cached state, event log, worktree and the agent’s MCP configuration, under ~/.rovara/loop/. Nothing is written into your Claude Code or Codex settings.
GitHub: the issue holds the truth: its comments and its rovara:* label.
Credentials: the loop uses your own gh login and stores no token.

Full Rovara loop guide →