feat(release): state the GitHub-only limitation as a decision

[TitusKirch]

Summary

release is GitHub-bound end to end, but the skill said so only in passing — "v1 is GitHub via the gh CLI" reads as not yet, implying a GitLab driver is on the way. Since #185 landed and forge accepts a second value, a GitLab repo adopting these skills had no way to learn the limitation from the skill itself; it found out when the skill stopped.

The feasibility question is settled: release-please is GitHub-only by construction, and the release-PR model this skill drives has no tool with real GitLab traction behind it (semantic-release tags straight from the pipeline — no release MR, so nothing to validate and nothing to merge). releaser-pleaser does reproduce the model on both forges, so a GitLab driver is technically reachable — and not worth reaching, for a forge no repo here is on.

So the change is the statement, not a driver:

• SKILL.md — the frontmatter description, the skill's opening paragraph, the detect step's forge bullet and the guardrail now say GitHub-only and say why: the release tool binds it, not the forge. The stop path explicitly must not say "not supported yet".
• REFERENCE.md — a new GitHub-only, and why the release tool binds it section (the first ##, where a GitLab reader looks), with a table of the four candidates and why each fails to unbind the skill; plus a Decisions entry recording the rejected options so the question is not reopened from scratch. The existing forge-key decision is updated — its "a second forge docks as a value" prediction held with ADR-0028.
• Generated artifacts refreshed via pnpm skills:sync (root README table, skills/repo/README.md).

The existing seams stay untouched on purpose. The release tool is detected rather than configured, and the skill's name is deliberately tool-neutral — so a tool that does reproduce the model docks here as detection, without a rename or a config break. Nothing here closes that door.

Type of change

• Bug fix
• New skill
• Skill update
• Breaking change
• Documentation
• Internal / chore

Checklist

• pnpm verify passes locally
• Tests added or updated — or not applicable (prose-only; test/ deliberately does not cover skill prose)
• Affected skill's SKILL.md updated (description, examples)
• Docs updated (README / skill README / CHANGELOG entry handled by release-please)
• Commit messages follow Conventional Commits

Test discipline

Prose-only change — SKILL.md and REFERENCE.md, plus the artifacts skills:sync regenerates. No code touched, so tdd was not driven; per the implement loop's rule that is a defined outcome, not a gap. The gate that did run is the repo's own: pnpm verify (lint, format, skills:check, typecheck, 199 tests) green in a fresh worktree after pnpm install --frozen-lockfile.

Related issues

Refs #186

[TitusKirch]

AI review — accepted (round 1 of 3, head 64abf86).

Scope match. Every item the issue asked for is present and nothing beyond it: SKILL.md states GitHub-only and names the release tool as the binding (frontmatter description + metadata.summary, the opening paragraph, the detect step's forge bullet, the guardrail); REFERENCE.md opens with a GitHub-only, and why the release tool binds it section carrying the four-candidate table; and the Decisions section records the rejected options (releaser-pleaser, semantic-release, GitLab release-cli, leaving it unscoped) so the question is not reopened from scratch. The stop path explicitly forbids "not supported yet" — the exact wording the issue called out.

Seams intact. "Release tool is detected, not configured" and the tool-neutral skill name are untouched and both are called out as deliberately open, as the issue required.

Correctness. All four cross-links resolve — REFERENCE.md#github-only-and-why-the-release-tool-binds-it, REFERENCE.md#decisions, and SKILL.md#1-detect-read-the-repo--never-assume. The frontmatter description is 848 chars, inside the spec's 1024 limit (Conformance green). A grep over skills/repo/release/ finds no surviving forge-staging wording; the remaining "v1" mentions are about release-tool detection, which genuinely is staged. Generated artifacts: the root README table and skills/repo/README.md were refreshed for the new summary; plugin.json and skills.sh.json carry only paths and names, so no drift there — confirmed by skills:check.

Gate re-established, not inherited. pnpm install --frozen-lockfile + pnpm verify run here against origin/ai/186-release-github-only in a throwaway worktree: exit 0 (lint, format, skills:check, typecheck, 199/199 tests). Forge checks agree — Verify, Conformance and both CodeQL analyses green.

Risk. Prose-only, no code, no secrets in the diff. No CODEOWNERS file and no branch protection on dev, so no human reviewer is required. Accepted.