forge-hostlisted

<!-- forge-host-version: 20 --> # forge-host: host-aware forge operations Several forge-kit components assume GitHub: they shell out to `gh`, hit `api.github.com`, read `.github/workflows/`, or carry a `{{GITHUB_REPO}}` placeholder. When a repo moves to a self-hosted **Forgejo** (or Gitea) instance, those stop working. This skill makes the forge operations **host-aware** behind one adapter, so the same governance logic runs on either host. > **One adapter, not two skills.** Closing an issue, cutting a release, or checking CI is the *same > contract* with a *different transport*, an adapter concern. A single `forge-lib.sh` (the analogue > of `release-automation`'s `version-lib.sh`) keeps the contract in one place; per-host quirks live > in `references/`, not a second skill. ## The model - **Detect the host per-repo** (never assume GitHub), deterministically, so it works unattended in CI/hooks, not just interactively. - **Abstract the operations** the components need (issues, comments, releases/tags, CI status) behind `forge_*` functions with two backends: **GitHub (`gh`)** and **Forgejo (`curl` + REST)**. - **Additive:** a repo with no `.forge.conf` defaults to GitHub and behaves exactly as today. Both backends speak **REST** (GitHub via `gh api`, Forgejo via `curl`), *not* `gh`'s porcelain, because Forgejo's API is the Gitea API, whose JSON shapes for issues/releases/comments closely match GitHub's REST, so callers' `jq` parsing stays identical across hosts. ## Hos