How it works · Talooner

Talooner splits into two halves that never share secrets: an ephemeral CI runner that talks to your forge, and a self-hosted cluster that holds the rules and the model credentials. The runner extracts facts and executes actions; the cluster does all the reasoning. Same commit, same rules, same verdict — every time.

The flow, step by step

Trigger. A PR/MR event fires, or a maintainer comments !talooner /review.
Extract facts. The ephemeral runner reads the forge API with its scoped token: pr.*, user.*, review.*, the diff, changed files, CI status.
Evaluate. Facts cross to the cluster over gRPC (evaluate_pr). The tln engine loads the repo's ruleset and resolves the verdict. Most PRs never touch a model.
Consult a model — only if a rule asks. Where a rule says do llm_review, the executor calls a model with the code-unit's state plus a typed question. With TypeSafe / Jev that answer comes back as a typed decision with calibrated confidence — a Choice, a Score, or a Noul (true/false, 0–1) — which re-enters the engine as an ordinary fact (llm.risk, llm.risk_confidence, …). Not prose.
Act. The engine returns a list of actions; the runner executes them on the forge — a check run / commit status, one sticky review comment, an advisory approve/block, assignees and review requests — then exits.

Works with your agents

Talooner reviews the pull request, not the tool that wrote it — so it fits whatever your team already uses to write code. Native integrations are on the way.

Runs on

OC OpenClawcoming soonTalooner as the guard inside your OpenClaw agents — rules check the work before it leaves.

HE Hermes Agentcoming soonNous Research's open-source agent — Talooner rules check its work before it ships.

DV Devincoming soonTalooner rules applied to Devin's work before its pull requests reach your team.

OT OpenTaloncoming soonTalooner rules and the tln engine running inside your self-hosted OpenTalon cluster.

Reviews PRs from

CC Claude Codecoming soonAgentic coding in the terminal and CI, opening PRs on your forge.

CX OpenAI Codexcoming soonCloud coding agent that hands its work back as pull requests.

GC GitHub Copilot agentcoming soonAssign it an issue, it opens a PR — Talooner reviews it first.

CU Cursorcoming soonBackground agents that push branches and open PRs.

FN Flow-Nextcoming soonPlan-first Claude Code / Codex workflow — its overnight Ralph runs meet your rules before merge.

FD Factory Droidscoming soonFactory's agents that take a ticket all the way to a pull request.

OH OpenHandscoming soonOpen-source coding agent that turns issues into pull requests.

JU Julescoming soonGoogle's asynchronous coding agent that works in a VM and opens PRs.

KI Kirocoming soonAWS's spec-driven agentic IDE — specs become code, code becomes a PR.

AI Aidercoming soonAI pair programming in the terminal that commits straight to git.

Autonomous loops coming soon — tools that code unattended overnight (Flow-Next's Ralph mode, agent task runners) produce exactly the "insurmountable wall of pull requests" no reviewer can read. Talooner can be their last gate: the loop asks talooner rules plan --repo … --pr … before it hands off, sees "needs security review" or "blocked: too large", and fixes it before a human ever looks.

Because the author is just a fact, a rule can treat agent-written PRs differently:

rule "Agent-authored PRs get an owner review" {
  for records where type == "pr" and attr "pr.author" ends_with "[bot]"
  requires "review.owner"
  do assign "pr" attr "user.owner"
  do comment "pr" "Opened by {attr.pr.author} — the code owner signs off before merge."
}

Why this shape

The credential boundary is the whole point. The runner holds only a scoped, short-lived forge token. The model credentials live in the cluster you run, so every token a rule spends is billed to whoever ran the rule. Nobody's review load lands on someone else's API limits.
Typed output makes confidence a first-class gate. A rule can act on a high-confidence verdict and escalate to a human on a low one — something you can't express cleanly against free-text LLM output.
Determinism where it counts. The engine is deterministic. The single probabilistic hop is isolated behind do llm_review and cached per code-unit, so its variance is contained rather than driving the verdict.