Releasewright

Releasewright closes the loop after the code is written. Code is no longer the slow part: planning, review, security, packaging, release and watching it run are. We built a small link checker for this project (Python standard library, MIT, first commit 2026-10-16) and wrapped it in a GitLab pipeline and GitLab Duo Agent Platform flows that carry one issue all the way to a tagged release.

Who it is for: solo maintainers and small teams who ship a package or CLI from GitLab and have no platform engineer. For them one release is a chain of 11 separate steps (counted below) across the issue tracker, the code, the changelog, the tag and the release page, and all of them land on the same person. We chose this audience because the recorded run uses only what such a project already has (a GitLab project, shared CI, the Releases API with the job token, Duo flows) and no extra service; a platform team that already owns its release tooling is not the target.

Measured, one recorded run (2026-10-16 UTC, re-read on the public API 2026-10-17 00:29 UTC): issue #4 created 17:42:55 to release v0.2.0 created 17:54:51: 11 min 56 s, 3 flow sessions (Developer 9617666, Triage Plan 9617673, Release Notes 9617963), 3 human acts, about 1.5 GitLab Credits per session (10.71 credits for 7 sessions; the owner's dashboard has no per-session split). The same change by a person is 11 steps; with the loop a person does 3 (create and assign the issue, arm merge on the two merge requests) and flows and CI do the other 8. No manual timing was measured, so we claim no time saving, only the 11 min 56 s.

Without the loop (person)	With the loop
create issue, write criteria, branch, code and tests, open MR, review and merge, choose version, edit changelog and notes, open release MR, review and merge, tag, publish release (11 steps)	create issue (person), criteria / code / MR (Triage Plan and Developer flows), merge arm (person), version / changelog / notes / release MR (Release Notes flow), merge arm (person), tag and release (CI): 3 person steps

What happens in one run (all visible in the project):

A person creates an issue from the feature template and assigns Duo Developer (human act 1 of 3).
Our custom Triage Plan flow reads the issue and the code and posts numbered, testable acceptance criteria and a file list, then labels the issue ready-for-dev.
The foundational Developer flow implements it and opens a merge request with tests.
The 9-stage pipeline runs: plan, create, verify, secure (SAST and secret detection), package (wheel), configure (config-as-code check), release, govern (license report, DCO report), monitor.
A person reads the merge request and arms auto-merge (human act 2 of 3). GitLab itself blocks AI workflows from merging (/merge returns 403), so the human gate is real, not staged.
On the green main pipeline our custom Release Notes flow reads the merged work, picks the next version and opens a "Release vX.Y.Z" merge request with written notes. After the third human act (approving the release merge request), CI creates the tag and the GitLab Release through the Releases API with the job token. No human tags or publishes.

Where the human gates sit (the project README draws this as a diagram): human act 1 (issue) starts Triage Plan and Developer; Developer's merge request goes through the pipeline to human act 2 (merge); the green main pipeline starts Release Notes; its release merge request goes to human act 3 (merge); CI then tags and releases. Separately, a scheduled monitor:probe that finds a dead URL starts Monitor Incident, which opens an issue; a person has to assign that issue to restart the loop (not automatic).

What is different:

Version chosen by an agent from merged work, no commit convention. semantic-release "uses the commit messages to determine the consumer impact", by default in the Angular commit format. Our Release Notes flow reads the merged merge requests and the changelog instead and states its rule in the MR: "Latest tag is v0.1.0. Unreleased has an Added feature entry (--timeout option), so the minor version is bumped and patch reset: 0.1.0 -> 0.2.0. No breaking change was inferred; a human should confirm none exists." It never picks a major version.
No human tags. release:publish calls the Releases API with the CI job token, which creates the tag; the public job log shows 201 v0.2.0.
Incident de-duplication. Monitor Incident searches open issues for the same URL before filing and adds a note to the existing one instead of a second issue. The one recorded run found no duplicate and said so; the existing-issue branch has not been run.
The platform's 403 on AI merge is a real gate. The first release run reported: "GitLab rejected /merge for AI workflows (403), so this MR needs a human to merge it." We kept the gate and did not add a token-based merge job to get around it.
Evidence per stage. The README links one job per stage (plan to monitor) from the same run.

Duo features used: three custom flows with their own triggers (Triage Plan, Release Notes, Monitor Incident), two custom agents (Compliance Summary, Release Notes Editor), the foundational Developer flow, AGENTS.md and agent-config.yml for the flow runner. Autonomy level: Supervised (a person approves the outcome of each merge request, not each action).

Monitor stage: a pipeline schedule runs monitor:probe over a URL list. On a demo branch with one deliberately dead URL the probe failed, the Monitor Incident flow read the job log, found no duplicate and opened issue #5 with the cause and the pipeline link (session 9619711). The first attempt opened nothing because the probe printed no table to the job log; the probe now prints it.

Honest limits: the Monitor run was started on demand ("Run now") and the dead URL exists only on the demo branch; the schedule is not enabled on main. The three human acts in the recorded run were performed by the AI agent through the entrant's logged-in account. Nothing is deployed outside GitLab; the release page and the wheel artifact are the output. What is public, checked without signing in on 2026-10-17 00:29 UTC: issues, merge requests, pipelines (19 started by flows, 17 succeeded), job pages and job logs, and release pages. The flow session pages (/-/automate/agent-sessions/<id>) answer 404 to an anonymous visitor, so session ids are matched through the issue and merge request notes.

Credits: 44.73 of 500 monthly GitLab Credits for everything run in October so far (the recorded loop, two baseline releases, a dry run of the demo, the Monitor demo, agent runs and the release v0.3.1; GitLab Credits dashboard read 2026-10-17 11:08 KST). One full issue-to-release run with Monitor costs about 7 credits (measured in the dry run).

AI disclosure: the code, flows, agents, documentation, video and narration were produced by Claude (Anthropic) and run through GitLab Duo Agent Platform. The entrant selected the contest and project and, before submitting, reviews the finished work. The three human acts shown in the video (issue, two merge approvals) and the start of the Monitor schedule run were done by the AI agent through the entrant's GitLab account. The entrant watched the video and approved this submission on 2026-10-17.

License: MIT. Contributions use a DCO sign-off; govern:dco checks each pipeline's commit range: agent commits are listed for a human sign-off, an unsigned human commit fails the job.