Home/Onboarding

A few questions. A tested policy. One pull request.

Answer a few questions about your repository; Talooner writes them down as a spec, builds tested rules from it and opens the pull request — from your terminal or your coding agent.

Run it Let your agent do it

~/acme-shop

How it works

Ask first, then build

Onboarding doesn't guess what matters in your repository — it asks, writes your answers down, and builds the rules from them.

step 1
Ask
A few questions: which paths are sensitive, who reviews them, which extra rules you want.
step 2
Spec
Your answers become .talooner/onboarding.md — shown to you, approved, committed.
step 3
Rules + tests
The rules are built from the spec, then every test passes before you see them.
step 4
Pull request
Rules, tests, spec and the CI step on one branch — you review and merge.

The spec

Your answers, kept next to your rules

Read by default. Every later run builds from.talooner/onboarding.md— no flags.
Edit and rerun. Add a path, change a reviewer, run onboard again: the rules follow.
The policy explains itself. It's committed with the rules, so a reviewer sees why billing changes wait for @acme/payments.
AI review only where you have it. Offered when your license includes it — with decision-model triage first where your cluster has a decider.

.talooner/onboarding.md

# Talooner onboarding spec

## Sensitive paths

Changes here wait for a review before merge.

- `billing/` — payments — reviewed by @acme/payments
- `db/migrations/` — database migrations — reviewed by @acme/dba
- `internal/auth/` — authentication — reviewed by @acme/security

## Extra rules

- PRs need a description
- Very large PRs are split before review
- New dependencies need a security review

## AI review

on

Run it

One command, three ways

On your machine

From the repository's root. -it lets it ask; --user makes the files yours.

cd path/to/your-repo
docker run --rm -it \
  -v "$PWD:/repo" --user "$(id -u):$(id -g)" \
  -e TALOONER_LICENSE_KEY \
  -e TALOONER_MODEL_BASE_URL -e TALOONER_MODEL -e TALOONER_MODEL_API_KEY \
  -e CDM_URL -e CDM_TOKEN \
  ghcr.io/talooner/talooner-runner:latest onboard

A repository on GitHub or GitLab

No clone needed: a token that can read it. The files are printed, or written to --out <folder>.

docker run --rm -it \
  -e TALOONER_LICENSE_KEY -e GITLAB_TOKEN \
  -e TALOONER_MODEL_BASE_URL -e TALOONER_MODEL -e TALOONER_MODEL_API_KEY \
  -e CDM_URL -e CDM_TOKEN \
  ghcr.io/talooner/talooner-runner:latest \
  onboard --repo gitlab.com/acme/shop

Straight to a pull request

Add --pr: rules, tests, spec and the CI step land on a talooner-onboarding branch.

docker run --rm -it \
  -v "$PWD:/repo" \
  -e TALOONER_LICENSE_KEY -e GITLAB_TOKEN \
  -e TALOONER_MODEL_BASE_URL -e TALOONER_MODEL -e TALOONER_MODEL_API_KEY \
  -e CDM_URL -e CDM_TOKEN \
  ghcr.io/talooner/talooner-runner:latest onboard --pr

Guides, written with your coding agent

Your docs become the review

The AI review checks each changed part of the code against the doc linked to it in .talooner/architecture.yaml. With the onboarding skill, your agent writes those guides with you: it asks which mistakes have hurt you, what must never happen and which tests must exist — then checks the guides against your current code before anything is committed.

One rule per section. Each heading names one rule, so the review can answer it on its own — a section that mixes three rules gets “not sure”.
Checkable, not vague. Your agent asks what a reviewer would point at: a call, a check, a name, a number. “Clean code” becomes “no rescue that returns nil”.
A gotcha with the wrong code. The typical mistake, written down. It turns a likely finding into a certain one.
Required specs per file. A list of the cases each file's spec must test — the review flags a missing one, or one that tests something weaker.
Your rules stay a handful of generic ones for every file; what's specific to your codebase lives in docs your team reads too.

## Money

### Refund cap

A payment can be refunded in parts; the sum of all refunds
never exceeds the charge.

> **Gotcha**: comparing only the new amount
> (`amount_cents > payment.amount_cents`) lets two partial
> refunds add up to more than was paid.

## Specs

### app/services/payments/refund.rb

- **Refund over the cap including earlier refunds**: a second
  refund that fits the charge but not the remainder raises
  `TooLarge`.

Decision rules, written for you

Typed decisions on every PR — automatically

With a context decision model connected and AI review in your license, onboarding doesn't stop at path rules. It writes decisions on the PR itself — how risky is it, does the description say why — and rules that act only on a confident answer.

PR #128

Rewrite session token signing

Switches HMAC keys and drops the old verifier.

tool "cdm" "decide"0.11 s

low0.02
medium0.05
high0.93

high and certainty ≥ 0.85?

!high · 0.93 — not passed

held for a senior review

A label and a certainty, not prose. The model answers with one of the choices and how sure it is — the rule reads both.
Gated at 0.85. An unsure answer does nothing; a failed call is error and never fires a rule.
Cheap enough for every PR. About a tenth of a second, a fraction of a cent — see the math.
Tested like the rest. Each decision rule ships with tests for the confident case and the unsure one.

enrich "cdm: how risky is this PR?" {
  for records where type == "pr"
  stale_after 1 hour
  tool "cdm" "decide" {
    state   concat(attr "pr.title", "\n\n", attr "pr.body")
    choices "low, medium, high"
  }
  update attr "pr.risk"           from result.chosen
  update attr "pr.risk_certainty" from result.certainty
}

rule "Hold high-risk PRs for a senior review" {
  for records where type == "pr"
    and attr "pr.risk" == "high"
    and attr "pr.risk_certainty" >= 0.85
  do block "pr.merge"
  do require "review.senior"
}

What it reads

The shape of your repository — never the code

Folder names three levels deep, the README's first lines, and three files as they are: the spec, CODEOWNERS (who reviews what) and the CI file it adds its step to. Those go to the cluster inside the container and, if you set one, to your own LLM provider. Nothing reaches us except the license check.

▸ acme-shop/
▸ .github/workflows/
talooner.ymlread as is
▸ .talooner/
onboarding.mdread as is
▸ app/billing/
invoice.rbnever read
▸ db/migrations/
20261012_add_vat.rbnever read
▸ internal/auth/
session.gonever read
CODEOWNERSread as is
README.mdfirst 40 lines
.gitlab-ci.ymlread as is

name onlyfirst 40 linesread as isnever read

What you need

1Docker. The same image as the pipeline step — nothing else to install.
2Your license key. In TALOONER_LICENSE_KEY — from your license page, or a free demo license.
3Recommended: any LLM. Behind an OpenAI-compatible API (Qwen, DeepSeek, your own servers), or ANTHROPIC_API_KEY / OPENAI_API_KEY. Without one you get the starter ruleset to edit by hand.
4For decision rules: CDM_URL + CDM_TOKEN. The endpoint and key of a context decision model (Jev from typesafe.ai, SubQ Snap from subq.ai) — with AI review in your license, the generated rules use its decisions too.

Then

Read the rules and adjust them — the rules guide shows what they can match on — and run the tests after every change. The CI step runs them before every review too.

docker run --rm -v "$PWD:/repo" -w /repo --entrypoint tln \
  ghcr.io/talooner/talooner-runner:latest test .talooner/

Need help?

The Talooner team can help with onboarding your project.

Message us

Let your coding agent do it

Your agent asks the questions. Talooner builds the rules.

A SKILL.md for Codex, Cursor, Claude Code, Qwen Code or any other agent: it interviews you, writes the spec with you, writes the guides the AI review checks against, runs onboarding, tailors the rules to the code it can see, keeps the tests green — and asks before it commits.

Download SKILL.md

then ask: “onboard this repo to Talooner”