Prompt release automation when changelog indicates release readiness

[coisa]

Context

Agents currently help maintain changelog entries and release PRs, but they do not proactively identify when the changelog is already signaling release readiness. That means fixes can sit in Unreleased, or the unreleased section can accumulate enough changes, without the agent asking whether it should start the release workflow.

We should teach either a dedicated release agent or the existing changelog / PR agents to recognize that moment and guide the release flow without bypassing human intent or branch protection.

Proposed behavior

When an agent finishes work that touched CHANGELOG.md, reviews an implementation PR, or otherwise inspects release readiness, it should check the Unreleased section.

The agent should ask whether to trigger the release workflow when either condition is true:

• Unreleased contains at least one Fixed entry.
• Unreleased contains at least five entries across its subsections.

If the user confirms, the agent should:

• Dispatch the release workflow that prepares the release PR.
• Wait for the release PR to be created or updated and report the PR URL.
• Ensure the release PR has the expected validation flow running, including tests and wiki/report generation when applicable.
• Wait for checks to finish when practical; if validation fails, stays pending, or cannot be observed reliably, report that clearly and stop before requesting merge.
• Run the normal pull-request review flow against the release PR.
• If the release PR only contains expected release surfaces, such as changelog updates, release notes, and workflow-managed wiki output, and all required checks pass with no review findings, request merge or enable the repository-approved merge path.

Candidate touch points

• .agents/agents/changelog-maintainer.md
• .agents/agents/issue-implementer.md
• .agents/skills/changelog-generator/
• .agents/skills/github-pull-request/
• .agents/skills/pull-request-review/
• Release workflow dispatch documentation around .github/workflows/changelog.yml

The implementation may be a dedicated release agent, additional rules in the existing changelog/review agents, or a small shared checklist referenced by both. Prefer the smallest change that keeps the behavior consistent across issue implementation, changelog maintenance, and PR review.

Acceptance criteria

• The relevant agent or skill can detect whether CHANGELOG.md has Unreleased fixes.
• The relevant agent or skill can count unreleased entries and use 5 as the default prompt threshold.
• The agent asks the user before dispatching any release workflow.
• On confirmation, the agent dispatches the release workflow and records the workflow run or release PR URL.
• The agent waits for the release PR to appear, then verifies that expected checks and generated-output workflows have run or reports why they could not be verified.
• The agent runs the pull-request review routine on the release PR before requesting merge.
• The agent only requests merge when the release PR is limited to expected release-generated surfaces and all required checks pass.
• The agent reports blockers instead of requesting merge when checks fail, remain pending, include unexpected file changes, or review finds issues.
• The behavior is documented in the affected agent or skill instructions.

Non-goals

• Do not dispatch release workflows silently without user confirmation.
• Do not bypass failed or pending required checks.
• Do not automatically merge release PRs that contain code, workflow, or dependency changes outside expected release-generated files.
• Do not require every changelog edit to trigger a release prompt; only use the fixes and entry-count thresholds above.

Open questions

• Should the five-entry threshold count every bullet under Unreleased, or only top-level changelog items after generated/grouped entries are normalized?
• Should the agent request merge, enable auto-merge, or ask for a final confirmation when all release-only validation passes?
• Which release workflow inputs, if any, should be inferred from the current changelog state versus requested from the user?