Offloop
Sign in
Agent team templates

Software Release Checklist

Give the release owner a decision-ready record: what will ship, where it will run, which checks apply, and how the team will observe the result. Copy the checklist or prepare the packet with your Engineering team.

Explore this team See an example

Software Release Checklist for Engineering Teams · Built on the Engineering team

How the team moves the work forward

  1. 1 / CI Investigation Agent

    Match checks to the candidate

    List passed, failed, pending, and unavailable results with revision and environment. A result for another build is a separate record.

  2. 2 / QA Agent

    Inspect readiness and user paths

    Identify the user workflows and compatibility boundaries this release affects. Connect each required check to its evidence or unresolved owner.

  3. 3 / Release Sentinel Agent

    Prepare the decision and readback

    Assemble the go/no-go questions, rollout plan, recovery constraints, and post-release observations for the authorized release owner.

See what you can work toward

Illustrative outputs. Your team works from your own materials.

Fictional example. Replace the records, targets, and decisions with your own evidence.

Green tests with a missing compatibility check

Candidate: demo-build-19 for fictional staging service export-api.

Observed: supplied unit and API checks passed for demo-build-19.

Unverified: old workers reading the new event field have no supplied compatibility result.

Owner: service engineer to provide the compatibility evidence.

Decision: awaiting the release owner; the packet does not issue deployment approval.

The thinking behind it

Review the release boundary and its dependencies, not only the color of a pipeline.

This example explains the task. It is not a live run or a customer result.

Bring the context.
Give the team a good start.

Start with what you already have. The team can ask for missing details before preparing the next step.

Release identity
Supply the service, exact revision or artifact, target environment, included changes, and dependencies. Name the decision owner.
Readiness evidence
Attach relevant test, review, compatibility, and recovery-plan records. Keep missing evidence and accepted exceptions visible.
Rollout policy
Provide the approved procedure, observation criteria, stop conditions, authorized operator, and next checkpoint. Use your own system thresholds.

Make this your team.

Copy the starting task and adapt it to your work. With the Engineering team in your workspace, share it with Engineering Agent alongside your source materials.

Get the starting task

Team installation is currently in limited access. You can explore the team and copy the task and reference files here.

Editable template

Starting task for your Engineering team

software-release-task.md

Download
# Prepare software release readiness

Engineering Agent: ask CI Investigation, QA, and Release Sentinel to prepare a release packet from the supplied evidence.

Service and exact candidate revision/artifact:
Target environment:
Included changes and dependencies:
Authorized release owner/operator:
Applicable release policy:
Evidence references:
Rollout and recovery procedures:

For each applicable check retain its exact revision, environment, status, and source. Keep failed, pending, missing, and not-applicable distinct. Name unresolved owners. Include compatibility, accepted/in-flight work, recovery constraints, observation thresholds, and the next checkpoint where relevant.

Return a readiness summary, human decision field, rollout record, and post-release readback checklist. Do not approve, merge, deploy, change controls, or claim unobserved checks succeeded. Request missing source access.

Reference files, when you need them

Use these editable templates as inputs or work with them on their own. Free to copy and download. Worked examples use fictional records.

Blank software release checklist

Editable template

Blank software release checklist

software-release-checklist.md

Download
# Software release checklist

Service / environment:
Exact candidate revision and artifact identity:
Current serving revision:
Change scope and dependencies:
Release owner / authorized operator:
Applicable policy and decision deadline:

## Before the decision
- [ ] Scope and release identity match the reviewed change.
- [ ] Required review and checks have explicit status and exact source references.
- [ ] Old/new readers, writers, clients, and data changes are compatible where needed.
- [ ] Capacity and accepted/in-flight work are covered by the transition plan.
- [ ] User paths, operational observations, and stop conditions are defined.
- [ ] Recovery procedure and any irreversible effects are understood.
- [ ] Required communications and authorized owners are recorded.

## Evidence register
| Check | Candidate | Environment | Status | Evidence | Owner / unresolved condition |
| --- | --- | --- | --- | --- | --- |
| | | | | | |

## Human decision
Decision / reviewer / time / reviewed version:
Conditions or exceptions and their authorized owner:

## Execution record (completed by the authorized operator)
Actual operation reference and artifact:
Start/end times and scope:
Stop or recovery action, if any:

## Observed outcome
- [ ] The target runtime reports the intended artifact/revision.
- [ ] Changed user behavior has been exercised with retained evidence.
- [ ] Agreed observation window and thresholds have been evaluated.
- [ ] Affected pending work and any data effects have verified outcomes.
- [ ] Follow-up owners and next checkpoints are recorded.

A checkbox is a prompt to attach evidence, not deployment permission.
Worked readiness record (CSV)

Fictional worked example

Worked readiness record (CSV)

software-release-readiness-example.csv

Download
examplecheckcandidateenvironmentstatusevidenceownernext_action
fictionalAPI contractdemo-build-19stagingpassedDEMO-CI-42QARetain receipt
fictionalOld worker compatibilitydemo-build-19stagingunverified—Service engineerProvide compatibility result
fictionalRelease decisiondemo-build-19stagingawaiting decision—Release ownerReview unresolved conditions

Good to know before you start

How is this different from a code review checklist?

Code review evaluates a change and its implementation. Release readiness also covers the target environment, combined candidate, dependencies, rollout ownership, recovery constraints, and observed behavior after deployment.

Should every software release use the same checks?

No. Select checks for the affected boundaries and the current release policy. Record why a check is not applicable or which owner accepted an exception. Do not infer permission to skip a required control from this template.

Does completing the checklist deploy or approve anything?

No. It produces a decision record. Existing authorization, CI, and deployment systems own the actual release. This page does not connect a repository, change branch settings, or run a pipeline.

What if rollback is unsafe?

Record the incompatibility or irreversible effect and the approved recovery procedure. Do not present a previous artifact as a usable rollback without verifying the data and dependency constraints.