release

What it does

Derives a version bump for a chosen release target from the commit history since that target's last tag, updates the target's changelog, creates a tag within the target's namespace, and, upon explicit authorization, publishes a GitHub Release with the changelog as notes. It requires exactly one argument—the target name—and enforces that if multiple targets exist, a target must be provided. If no target is provided for a single-target project, it uses the declared single target mechanically. The process uses a shared helper to read the declared release targets, resolve the target row, and obtain fields such as tag prefix, changelog, manifest, and payload. Commands and helper scripts are invoked exactly as specified, with an interpreter resolution step to choose between python3 and python, and with careful handling to avoid executing row-provided values until after human authorization. The flow emphasizes reading a single row per target and explicitly avoiding per-target prose or inline evaluation of the row values. If the target is unrecognized, the operation stops; missing declared files trigger a back-fill path rather than an outright failure. The interpreter and helper invocations are designed to work across POSIX environments, with noted caveats for Windows hosts.

How it works

• The skill reads the declared targets from {{PROJECT_DIR}}/.codearbiter/release-targets.md to determine available targets.
• It resolves the target to a row via the helper: TAG_PREFIX=$("$PY" "{{PLUGIN_ROOT}}/hooks/_releaselib.py" tag-prefix $TARGET) and reads fields using show-row with --field (e.g., CHANGELOG, MANIFEST, PAYLOAD, ARTIFACTS, REBUILD, PRE_TAG, etc.).
• It derives the version bump by inspecting the Conventional-Commits history since the target's last tag, and updates the target's CHANGELOG accordingly.
• It writes an annotated tag in the target's namespace using the resolved TAG_PREFIX and the derived version.
• It, upon explicit authorization, publishes a GitHub Release with the target’s changelog notes. The tag and Release are not published without authorization.
• It enforces that if more than one target is declared, the user must specify the target; otherwise, it STOPs and asks for clarification. It resolves the omitted-single-target case mechanically by listing targets first, then proceeding.
• It includes a detailed interpreter resolve mechanism to choose between python3 and python and uses a consistent invocation pattern: "$PY" "{{PLUGIN_ROOT}}/hooks/<script>" <args>.
• It handles potential Windows-specific issues by documenting that Windows-hosted rows may require concrete interpreters in pre-tag, rebuild, and generate rows, and notes Windows shell behavior for subprocesses.

When to use it

• When you want to create a new release tag for a specific declared target on a non-default branch with a green test suite, using the target’s designated namespace and changelog.
• When a project declares multiple release targets and you need to specify which one to release for the next version.

What it can touch

• The release target’s namespace for the tag and the corresponding GitHub Release notes.
• The target’s CHANGELOG, MANIFEST, GENERATED_MANIFEST, and other related fields as read from the target row via show-row, and any commands defined in PRE_TAG, REBUILD, GENERATE, etc., for that target’s row.

Caveats

• A row that is not declared or unrecognized TARGET halts the operation; missing or malformed declared files trigger back-fill or parse errors rather than guesses.
• Windows hosting introduces interpreter considerations: Windows-hosted rows must keep a concrete interpreter in pre-tag, rebuild, and generate commands; using "$PY" may fail under cmd.exe.
• The release requires explicit authorization to publish the tag and GitHub Release; the tag and Release are never published without authorization.
• There may be multiple manifests; all manifests must be asserted to equal the derived version.