^{Originally posted by travi April 29, 2025}
i've been finding myself wanting to accomplish similar goals to what the cli package does, but in non-terminal contexts. i really like the convention of the octoherd script taking an octokit instance, a repo, and maybe some options, but the herd part of the equation is limited to being used within the cli. i'm wondering if there would be value in exposing some of the core herd functionality as a programmatic interface, possibly as a separate package.

i think the primary logic is essentially

, which might be so small that it is questionable whether it is valuable to pull it out vs duplicate in other clients. in general, i lean in the direction of sharing logic, even when small, but i think that is the big discussion point we'd need to align on before the rest of this thought matters.

the resolve-repositories logic could make sense as another function to expose, but that feels still a bit specific to the cli context in its current form.

in addition to the non-terminal context, exposing the core logic that expects an octokit instance and the list of normalized repos could be a way to enable alternative ways to determine the list of repos and support alternative auth options for octokit.

if this were available, that programmatic interface could enable other contexts beyond being from from a terminal, but would also enable embedding into other cli implementations. maybe this cli package becomes more of a reference implementation and easy default, but the programmatic interface is the path for more complex implementations?