1. Connect repository & LLM key → 2. Calibrate at least 1 metric → 3. Delegate in GitHub Issues
Apply flow:feature, flow:fix, or flow:plan on any GitHub issue to start. When Atobar needs your input (flow:needs-approval, flow:escalated, or a PR ready to merge), it assigns the issue or requests a PR review from your configured Human Assignee — 🔔 Assigned to Me ↗ · 👀 PRs to Merge ↗. Close an issue at any time to cancel and stop compute.
Onboard a repository to atobar-flow
atobar-flow runs everything remotely: agents, review rounds, arbitration and metric evaluation. Your laptop is only used once, to connect the repository. A repository becomes a tenant with its own wiki, metric definitions, observations and loop state, isolated from every other tenant.
Before you start
- You are an admin of the repository on GitHub.
git,curland the GitHub CLI are installed, andgh auth statusshows you signed in with therepoandworkflowscopes (gh auth refresh -s repo,workflow).- You have a local clone of the repository, up to date with its default branch.
- The repository may be empty: the script then pushes a first commit (README and trigger workflow) instead of opening a pull request, and the spec issue asks what to build from zero.
Part A: One-Time Repository Setup (~5 min)
| # | Stage | Who | Done when |
|---|---|---|---|
| 1 | Install the GitHub App on the repository (install, choose Only select repositories). | You | The repository is listed under Add a repository after you sign out and back in. |
| 2 | Register the tenant & issue token: click Add to atobar-flow, then
Generate token on the repository page. The token is shown once, and canonical flow:* labels
are seeded automatically. | You | Status onboarding, arbitration
shadow. |
| 3 | Configure LLM key, role models & Human Assignee on the repository page (LLM keys, Model per role, and Human Assignee & Reviewer). | You | LLM readiness and Human Assignee rows are green. |
| 4 | Run the onboarding script & merge the trigger PR in the clone:curl -fsSL https://cp.atobar.org/onboard.sh | bashIt checks your access, saves the token as the ATOBAR_TENANT_TOKEN Actions secret (it never prints
it), opens a pull request adding .github/workflows/flow-trigger.yml, and opens an
evaluation spec issue labelled flow:onboard. Prefer to read it first?
curl -fsSLO https://cp.atobar.org/onboard.sh, inspect, then bash onboard.sh.
Source: atobar-flow/atobar-flow. | You | Trigger workflow is on the default branch. |
Part B: Metric Calibration & Go-Live (First CI Run on main)
| # | Stage | Who | Done when |
|---|---|---|---|
| 5 | Author & approve at least 1 metric in the Control Panel under Repository Metrics (Draft → Compile → Approve). | You | Metric shows on the repository page and opens a flow-metrics.yml PR. |
| 6 | Merge the flow-metrics.yml PR. Default-branch CI runs your metric probe and
reports observations. | atobar-flow, then you | "Metrics received in the last 24 hours" is done. |
| 7 | Active. Once every active metric satisfies min_samples on the default branch,
the tenant activates automatically. Applying flow:feature, flow:fix, or
flow:plan on any issue starts an agent run. | atobar-flow | Status active. |
| 8 | Graduate arbitration: shadow → recommend (posts a verdict and
requests a review from your Human Assignee) → auto_merge (merges when every gate passes). | You | atobar-flow handles the repository end to end. |
While a tenant is still in onboarding, applying a work label removes the label and posts a single
checklist comment so you can simply re-apply it once active.
Writing an evaluation spec
The spec says what "better" means for your business, in numbers. For each metric give:
| Field | Meaning |
|---|---|
key | snake_case name, e.g. proxyless_access_ratio. |
| Measurement | A command run in your CI whose last line of output is a number, e.g.
python .atobar/metrics/proxyless.py. Describe it; atobar-flow writes the probe. |
comparator, threshold | One of >= <= > < == and the
target, e.g. >= 1.0. |
baseline_mode | absolute (must meet the threshold) or
no_regression (must not get worse than the default branch). |
min_samples | Observations needed before the gate trusts the metric (default 1). |
| Why | The business outcome it stands for, and how it could be gamed. |
Good metrics measure outcomes a user would notice (for example "the monitor reads Ollama without a proxy
in front of it"), not implementation details ("uses library X"). Prefer one or two strong metrics. Changes to
.github/workflows/flow-metrics.yml or .atobar/metrics/ in an agent PR are routed to a
human, and their metrics are not trusted for that PR.
Author or update a metric any time from the Repository Metrics section on the repository page.