The workflow
Track a handful of repos from a GitHub organization in the GitHub panel, choosing them from a list rather than knowing their names in advance.
What happens today
A repo is tracked if a BB project's checkout points at it, or if its full owner/repo name appears in the extraRepos setting. To track anything else you type names into a free-text box, one at a time, with no way to see what is available.
For an organization this scales badly. Mine has 26 repos; tracking a third of them means typing eight owner/repo names correctly into a comma-separated string. There is no whole-owner option, and owner/* is not supported (#2540 covers it being discarded without a word).
What I would expect
A Repositories section on the plugin's settings page listing my GitHub account and every organization I belong to, each with its non-archived repos and a checkbox. Check a repo, it starts feeding the Issues and Pull requests tabs.
Two constraints shaped the prototype:
-
The selection cannot live in extraRepos. PluginSettingsHandle exposes get() and onChange() but no set() (https://github.com/get-bb/bb/blob/ad79bbb5e/packages/plugin-sdk/src/backend-contract.ts#L96-L109), so a plugin cannot rewrite its own declarative settings. The prototype stores checked repos in bb.storage.kv and unions the three sources in discoverRepos. Repos that come from a project checkout or from extraRepos render checked and disabled with the reason beside them, rather than pretending to be toggleable.
-
Whole-owner tracking is better solved by picking than by globbing. syncAll loops repos serially at four gh calls each, so expanding an owner into all 26 of my repos would mean 104 serial gh calls every five minutes. A picker keeps the tracked set to what the user actually wants.
Also worth deciding: repos added this way have no BB project, so defaultProject has to be set before Send agent works on them. The prototype says so inline when it is unset.
Prototype
Branch: https://github.com/MPIsaac-Per/bb/tree/feat/github-repo-picker (stacked on #2541, which it needs for the extraRepos parse split)
Contains an app.slots.settingsSection with collapsible owner groups, two RPC methods (listOwners, setRepoTracked), CLI parity through bb github repos --available / track / untrack per AGENTS.md, and README plus docs/configuration.md updates. Owners come from gh api user/orgs and gh repo list <owner> --no-archived, cached for five minutes.
Verified on a dev instance against live GitHub: three owners enumerated, checking a repo in the browser synced it and showed up in bb github repos, and a repo held by extraRepos rendered locked with its reason. 29 tests pass.
I do not know whether you want this feature or want it shaped this way, so filing per CONTRIBUTING.md before any PR. Happy to cut the CLI half, move the surface, or drop it entirely.
AGENT GENERATED
The workflow
Track a handful of repos from a GitHub organization in the GitHub panel, choosing them from a list rather than knowing their names in advance.
What happens today
A repo is tracked if a BB project's checkout points at it, or if its full
owner/reponame appears in theextraRepossetting. To track anything else you type names into a free-text box, one at a time, with no way to see what is available.For an organization this scales badly. Mine has 26 repos; tracking a third of them means typing eight
owner/reponames correctly into a comma-separated string. There is no whole-owner option, andowner/*is not supported (#2540 covers it being discarded without a word).What I would expect
A Repositories section on the plugin's settings page listing my GitHub account and every organization I belong to, each with its non-archived repos and a checkbox. Check a repo, it starts feeding the Issues and Pull requests tabs.
Two constraints shaped the prototype:
The selection cannot live in
extraRepos.PluginSettingsHandleexposesget()andonChange()but noset()(https://github.com/get-bb/bb/blob/ad79bbb5e/packages/plugin-sdk/src/backend-contract.ts#L96-L109), so a plugin cannot rewrite its own declarative settings. The prototype stores checked repos inbb.storage.kvand unions the three sources indiscoverRepos. Repos that come from a project checkout or fromextraReposrender checked and disabled with the reason beside them, rather than pretending to be toggleable.Whole-owner tracking is better solved by picking than by globbing.
syncAllloops repos serially at fourghcalls each, so expanding an owner into all 26 of my repos would mean 104 serialghcalls every five minutes. A picker keeps the tracked set to what the user actually wants.Also worth deciding: repos added this way have no BB project, so
defaultProjecthas to be set before Send agent works on them. The prototype says so inline when it is unset.Prototype
Branch: https://github.com/MPIsaac-Per/bb/tree/feat/github-repo-picker (stacked on #2541, which it needs for the
extraReposparse split)Contains an
app.slots.settingsSectionwith collapsible owner groups, two RPC methods (listOwners,setRepoTracked), CLI parity throughbb github repos --available/track/untrackper AGENTS.md, and README plusdocs/configuration.mdupdates. Owners come fromgh api user/orgsandgh repo list <owner> --no-archived, cached for five minutes.Verified on a dev instance against live GitHub: three owners enumerated, checking a repo in the browser synced it and showed up in
bb github repos, and a repo held byextraReposrendered locked with its reason. 29 tests pass.I do not know whether you want this feature or want it shaped this way, so filing per CONTRIBUTING.md before any PR. Happy to cut the CLI half, move the surface, or drop it entirely.