How it works

Talooner runs as one step in your GitHub or GitLab CI. The job starts the talooner-runner container: the bot extracts facts from your forge, the tln engine decides, the bot acts on the verdict, and the container exits. No server to host. Same commit, same rules, same verdict — every time.

The flow, step by step

1. Trigger. A PR/MR event fires, or a maintainer comments !talooner /review.
2. Extract facts. The bot reads the forge API with its scoped token: pr.*, user.*, review.*, the diff, changed files, CI status.
3. Evaluate. Inside the same container, the tln engine loads the repo's ruleset and resolves the verdict. Most PRs never touch a model.
4. 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 a context decision model — Jev or SubQ Snap — 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.
5. Act. The engine returns a list of actions; the bot 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

Reviews PRs from

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

• Everything stays in your pipeline. The job holds a scoped forge token and, if you set one, your own LLM key — both as CI secrets. 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.