release

Drive the repo's release-please flow to a shipped release — get the integration branch onto the release branch, wait for the release PR release-please opens, validate it, merge it. Manual invocation only: nothing here ever fires on its own, and every merge waits for a human.

This skill is GitHub-only, and that is a decision rather than a stage. What binds it is not the forge but the release tool: release-please is GitHub-only by construction, and nothing with real traction elsewhere reproduces its release-PR model — semantic-release tags straight from the pipeline, leaving this skill nothing to validate and nothing to merge. So a root forge key naming another forge is not "not yet, a driver is coming"; it means there is nothing here to drive, and the run stops and says so. The alternatives that were weighed and rejected: Decisions. The seams stay open on purpose — the release tool is detected, not configured and the skill's name is deliberately tool-neutral, so a tool that does reproduce the model on another forge docks here as detection, without a rename or a config break.

Opted out? If the repo config sets release to false, this skill is disabled for the repo — stop immediately and tell the user the release skill is turned off in .tituskirch-skills.json. An absent release block is not disabled. Check .release == false on the resolved config before any action. A missing jq or config exits non-zero too, so a pass is not evidence the config was read.

Workflow

1. Detect (read the repo — never assume)

• Forge — from the root forge key. github is the only value this skill drives, so any other value stops the run — and the message says why: this skill is GitHub-only because release-please is, not because a driver is pending. Never say "not supported yet"; that promises something nobody is building. Point at Decisions for what was weighed. Then confirm the repo is reachable: gh repo view --json nameWithOwner,defaultBranchRef. If it fails (no GitHub remote, or gh not authenticated), stop.
• Release tool — the tool is detected, not configured. v1 recognises exactly one: release-please (release-please-config.json + .release-please-manifest.json, plus a workflow running googleapis/release-please-action on the release branch). None recognised → stop and report that no supported release tool was detected, naming what v1 supports. This skill drives a release tool; it does not invent a release process.
• Branches — resolve the promotion chain: release.stages if set (integration branch first, release branch last), else [head, base] where head = release.head, else pr.base, else the default branch, and base = release.base, else the repo default branch. Never hardcode dev/main. Validate stages (non-empty, distinct branches, real refs) — malformed → report and stop. git fetch first, then show the whole chain (dev → … → base) in the plan. Chains.
• Config — .tituskirch-skills.json at the repo root (optional, committed). Keys: REFERENCE.md.

2. Promote along the chain (config-gated)