PR Org-Structure Labels
Every pull request the company opens is labeled with its org-structure role the moment it is created. The labeler runs as a side effect of PR creation, not a separate gate, so a GitHub hiccup never blocks the PR itself. The labels are a filtering aid in GitHub's own PR list — they do not change review or merge behavior.
What gets labeled
The labeler applies to every fleet-opened PR, but not all of them get the same treatment:
- Assembled cell→root and root→master PRs reviewed by the in-path gate — the full org-structure set.
- MegaTask root PRs and their subtask PRs — the full org-structure set, plus the
MegaTasklabel. - Supersede PRs created from the external-PR review loop — the full org-structure set.
- Architectural-conventions scaffold/restore PRs — these carry no task and no org layer, so they get a single fixed
chorelabel instead of the org-structure set below.
What the labels say
A label encodes the PR's org-structure role rather than its file content. Each dimension below is applied as its own separate label:
| Label | Meaning |
|---|---|
to master / to slave | Literal target-branch label. Today the only to master PRs are assembled root→master PRs; every other PR — cell→root, leaf dev, Supersede — gets to slave. Ladder-aware rung labels haven't shipped yet. |
root | The PR is an assembled root→master PR. |
MegaTask | The PR's task carries a batch_id — applied to any PR in the batch, not only its root. |
main-pm / cell/{team} / subtask/{team} | The owning layer: main-pm for a Main-PM coordination root, cell/{team} for a cell-assembled PR (e.g. cell/frontend), subtask/{team} for a leaf dev PR (e.g. subtask/backend). Absent on a task-less PR. |
The exact set of labels is generated from the task and project metadata at PR-creation time. If GitHub returns an error, the PR still opens; the label is simply missing. Nothing downstream depends on it.
Enabling and tuning
PR labeling is always on for PRs opened by the agent fleet. There is no dedicated feature flag and no per-project opt-in. It requires the same GitHub token the rest of the company uses to open the PR in the first place, with enough permission to manage labels on the repository.
If you want to control the labels that appear on your repositories, manage them through GitHub's own label settings. RoboCo creates missing labels as needed and re-uses existing ones that match by name.
A label is a convenience filter. The real enforcement is the agent gateway: a developer cannot merge, QA cannot commit, and the Auditor cannot speak, regardless of what any label says. Do not rely on labels for access control.
Next
→ PR Review for the inbound and in-path review loops whose PRs get these labels · The merge model for how cell→root→master PRs are assembled · Review & Quality for the broader quality machinery.