graduate-backlog

# Backlog Graduation Bridge a project's **in-repo backlog** onto a **forge issue tracker** at the moment the backlog outgrows a single contributor. The orchestration skills author a rich in-repo backlog — `docs/roadmap/roadmap.md` (phases → target versions → task lists), `docs/sprints/*.md` (plans/retrospectives), a Nygard ADR sequence, and a Keep-a-Changelog `CHANGELOG.md`. Once more than one person needs to see and claim that work, they need a tracker — but that transform is manual and uncodified. This skill performs it **conservatively**. The default is **thin-hybrid**: planning stays in-repo, and the tracker holds only incoming/reactive work plus — at most — the current milestone's tactical items. That is *light externalization*, not a board build-out. A richer board is opt-in (the `roadmap-visible` level), justified by a real need for roadmap visibility. > **The trigger is team scale, not exposure.** Graduation is driven by *who needs to see the work* > — the same signal as the t0→t1 tier bump ("more than one contributor"). It is **not** gated on > the **Public** distribution profile: a corporate team on an internal GitLab needs a board without > ever open-sourcing, and a solo public repo may never need one. Exposure gates *compliance > controls*, not *work organization*. (Workspace decision records: "Distribution-Profile Axis for > Compliance Qualification", "Work-Organization Graduation: Thin-Hybrid Backlog Externalization", > "Plugin Taxonomy by Lifecycle, Not Expo...