Add tools/sourcehut/ as a forge bridge for SourceHut (sr.ht). SourceHut is distinctive on two axes the framework doesn't yet handle: it supports both Git and Mercurial repos, and its review model is email-based (git send-email patch threads on mailing lists) rather than web pull requests. Supporting it forces the pr-management-* skills to treat "a patch series on a list" as a first-class review unit — valuable well beyond sr.ht.
Capabilities to provide:
- Repo + ref read across both git.sr.ht and hg.sr.ht (reuse the Mercurial shim for the Hg case)
- todo.sr.ht tracker: ticket read/write via the GraphQL API
- lists.sr.ht: read patch-series threads; map a patchset to the PR/MR review abstraction
- builds.sr.ht: CI status read
- GraphQL API across the sr.ht services
Why: SourceHut hosts a committed minimalist-tooling community — postmarketOS, parts of the Alpine/Sway/wlroots orbit, and many Unix-philosophy projects — and is the reference implementation of the email-patch workflow that the broader kernel-style development model uses. Teaching the skills to handle list-based patch review (here and, later, for LKML-style projects) is the real payoff.
Reference:
Add
tools/sourcehut/as a forge bridge for SourceHut (sr.ht). SourceHut is distinctive on two axes the framework doesn't yet handle: it supports both Git and Mercurial repos, and its review model is email-based (git send-emailpatch threads on mailing lists) rather than web pull requests. Supporting it forces thepr-management-*skills to treat "a patch series on a list" as a first-class review unit — valuable well beyond sr.ht.Capabilities to provide:
Why: SourceHut hosts a committed minimalist-tooling community — postmarketOS, parts of the Alpine/Sway/wlroots orbit, and many Unix-philosophy projects — and is the reference implementation of the email-patch workflow that the broader kernel-style development model uses. Teaching the skills to handle list-based patch review (here and, later, for LKML-style projects) is the real payoff.
Reference: