---
name: publish-change
description: Prepare and carry a reviewed change through the publication or release step explicitly requested under the consumer's process.
---

# Publish Change

Inspect contribution and release guidance, the exact checkout, existing edits
and current candidate. Establish which endpoint the user requested: commit,
push, pull request, merge, release or distribution verification. Readiness for
one endpoint does not establish the next.

For GitHub PRs, checks and remote evidence, follow the contained
[GitHub tool guide](../_shared/references/github-tools.md). Inspect the current
head, reviews and merge requirements; report provider state separately from CI.

For public release notes and changelogs, apply available Communication
`write-prose` or `edit-prose` audience guidance before release. Review the final
public body, including generated or appended text, for useful capabilities,
compatibility, installation/migration and material limitations. Keep internal
conversations, approval history, operational boundaries, unrelated exclusions
and qualification/release-gate commentary in internal handoffs and receipts.
If Communication is unavailable, perform this editorial check directly;
Project Management remains independently selectable.

For release mutations, follow [draft and published releases](references/release-lifecycle.md).
Permit authorized draft edits and explicitly approved draft publication only
after verifying exact repository, release identity, current `isDraft`, source,
artifacts and action. Refuse changes to already published releases, including
prereleases with `isDraft=false`. Missing state or identity drift requires a
fresh read and resolution before writing. Existing executable denials remain
binding across tools; instructions and prefix rules do not establish state-aware
enforcement or eliminate concurrent-publication races.

Prepare the concrete candidate before asking about an uncovered promotion.
Check the final diff, relevant validation, unresolved findings and source or
artifact identity. Describe the problem and resulting behavior in reviewer-facing
text, with validation and material limitations. When several ready steps need a
decision, present them together with their destinations, exact artifacts and
limits under the [delivery authority rubric](../_shared/references/agent-decision-rubric.md#delivery-authority).
Use the consumer's templates where required; omit conversational history and
abandoned approaches.

Before push, require the consumer's final verification procedure for the same
base and candidate: every locally runnable CI-selected check, with commands,
typed exit statuses and candidate identity. Focused development tests do not
substitute for the complete selected suites. Use an existing repository gate;
do not duplicate its command registry in this plugin. Recheck evidence after
source changes, and retain failed, interrupted, unknown and unavailable results
explicitly. A local pass does not establish hosted qualification or the next
publication endpoint. Advisory hooks are reminders unless their enforcement
has been independently verified.

The parent agent owns final readiness: inspect the actual candidate-bound
receipts, then state which delivery endpoint is complete and which gates
remain. A delegated success summary alone does not establish readiness.

For authorized delegation, assign `pm_release_preparer` bounded local files,
accepted version or release scope, and required evidence. Read the
[agent routing guide](../_shared/references/codex-agent-routing.md). The parent
owns publication, merges and tags under the user's authorization.

Follow native Git conventions for commits and pushes. Use the GitHub connector
with the current head SHA for an authorized interactive merge, subject to the
consumer's higher-priority rules. Ordinary issue and pull-request operations
may use the available connector or native `gh`; use `gh-steward` for composed
project changes. Recheck current state immediately before the authorized action.
Keep prior authorization through routine continuation; do not repeatedly ask
when the same scope and candidate constraints still apply.

For release or distribution, retain source revision, version, immutable artifact
identity and a verified receipt for each requested destination. Preserve failed
receipts and investigate ambiguous outcomes before retrying. A tag or successful
upload alone does not verify acquisition or a consumer's running version.

Finish with the achieved publication state, links or receipts, exact candidate
and remaining gates. Cleanup, installation, deployment and business data
publication require their own task authority. Follow the
[decision rubric](../_shared/references/agent-decision-rubric.md).