| name | dogent-release-publish |
| description | Publish an accepted Dogent release according to `dev/package.md`. Use when the user asks to update `CHANGELOG.md`, bump the version in `pyproject.toml`, commit and tag the release, build artifacts, or publish the release to GitHub. |
Dogent Release Publish
Prepare and publish an accepted Dogent release using the repo packaging workflow in dev/package.md.
Workflow
- Read
dev/package.md, pyproject.toml, CHANGELOG.md, and the current release status in dev/sprint_plan.md and dev/sprint_uat.md.
- Confirm the target release is accepted before publishing. If acceptance is still pending, stop and tell the user what remains open.
- Update
CHANGELOG.md with concise user-facing notes for the accepted release.
- Update the version in
pyproject.toml and any matching version locations required by the repo if needed.
- Run the package workflow from
dev/package.md: build artifacts, smoke-test when requested or when the workflow says it is recommended, and verify the expected files exist in dist/.
- When the user asked for a full release, create the release commit and git tag for the current version, then publish the release to GitHub with the built artifacts.
- Report the exact version, tag, artifacts, and any steps that were skipped.
Publish Rules
- Follow
dev/package.md instead of inventing a release process.
- Keep changelog entries limited to accepted user-visible behavior.
- Use non-interactive git commands.
- If the user asked only to prepare the release, stop before push, tag, or GitHub publishing.
- If packaging or publishing needs network or credentials, request the required approval or surface the blocker clearly.
Resources