Generate an executable, verifiable release checklist for internet software delivery. The input is the release scope and known constraints; the output is a release plan with clearly identified items to be confirmed; it does not execute deployments, modify production environments, or replace release approval.
Scope: This skill handles software releases (code, service, client, or infrastructure delivery). Content publishing such as articles, social media, and videos is out of scope; please use the content publishing skill in the media domain.
Customer-Readable Description
What This Skill Can Do
Provide release goals, version/branch, environment, changes, and service dependencies; when information is incomplete, a draft with items to be confirmed can still be produced first.
| What the Customer Wants | What the Skill Will Do | What the Customer Can See |
|---|---|---|
| Launch a software version | Compile the version, branch, artifacts, configuration, and dependent services | Phased release checklist and items with ownership to be determined |
| Control launch risk | Design testing, approval, rollback pre-flight gates, and stop conditions | Pre-flight checklist with determinable pass/block status |
| Confirm results after canary | Orchestrate canary scope, observation metrics, and verification steps | Canary and post-release verification checklist |
How the Customer Uses It
Describe the release goal in natural language, and provide as much as possible: service or product, target environment, version and source branch, artifact identifier, configuration changes, dependent services, desired window, approvers, and rollback plan. The following minimal input can be used:
release:
product_or_service: <服务或产品>
environment: <staging|production>
version: <版本或提交标识>
source_branch: <分支>
artifact: <镜像、包或构建产物标识>
config_changes: [<变更或无>]
dependencies: [<依赖服务>]
release_window: <时间窗口或待定>
Unknown information must be marked as "to be confirmed" and must not be guessed by the Agent as established fact. After the customer confirms the checklist, execute it according to their existing release platform and permissions; this skill itself does not release.
Dependencies and Installation
This is a pure methodology skill with no hard dependencies, optional enhancements, or third-party tool dependencies, and no private configuration needs to be created.
npx skills add soia-team/soia-open-dev-release-skills -g -a '*' -s soia-dev-plan-release-checklist -y
The configuration convention uses schema v2; if the customer needs to save team defaults, the following file can be created on their own machine; if not created, work from the input in the request:
~/.config/soia-skills/soia-dev-plan-release-checklist/config.yml
Do not record credentials, tokens, internal addresses, or real customer data in configuration or deliverables.
Workflow
- Confirm boundaries. Identify that this is a software release rather than content publishing; confirm the goal, environment, window, owner, and whether to only generate a plan. If the request is actually content publishing, explain that it should be redirected to the media domain and stop this process.
- Establish the release baseline. List the version, source branch or commit, artifacts and their sources, target environment, database or configuration changes, dependent services, and compatibility assumptions. Write missing items into the to-be-confirmed section.
- Generate pre-flight gates. For each item, provide the responsible role, evidence, and blocking rules: build artifacts are traceable, automated/manual tests pass, change review and approval are complete, dependencies are healthy, capacity and monitoring are ready, and rollback artifacts and steps are available. Gates without evidence must not be marked as passed.
- Design release and canary. Define batches, coverage per batch, observation duration, core success metrics, error budget or stop thresholds, and pause, rollback, and escalation owners according to the customer's release mechanism. When there are no thresholds, mark "to be confirmed" and do not invent values.
- Orchestrate verification. Provide pre-release smoke checks, gray release verification for each batch, full rollout confirmation, and post-release checks of functionality, performance, error rate, alerts, data integrity, and dependency chain. For each item, note the check method or source of evidence.
- Review executability. Check whether versions, branches, artifacts, configurations, dependencies, approvals, and rollback correspond to one another; pay special attention to backward and forward compatibility and rollback feasibility of configuration/database changes.
- Deliver and retain decision points. Output the checklist, precheck status, gradual rollout/verification steps, and open items. Only when the customer has explicitly authorized it and all relevant gates pass may entry into the actual release process be recommended.
Output Contract
The output is a Markdown release checklist, fixed to include the following sections:
- Release Summary: Scope, environment, window, version, branch, artifact, owner, and the "software release" scope statement.
- Change and Dependency Checklist: Code/artifacts, configuration, data or migration, dependent services, compatibility, and items to be confirmed; each item has a status (known/to be confirmed/not applicable).
- Precheck Gates: Testing, approval, observability, dependency health, rollback plan, etc., listing responsible roles, evidence, pass conditions, and blocking conditions.
- Gradual Rollout and Release Steps: Sequence, batch/scope, observation items, pass thresholds or values to be confirmed, stop/rollback actions, and owners.
- Post-Release Verification Checklist: Smoke testing, business-critical paths, errors and latency, capacity, alerts, data consistency, dependent services, and customer feedback entry points.
- Conclusion and Open Items: The conclusion that the next stage may proceed, that release is blocked, or that this is for review only; items to be confirmed must not be stated as passed.
Use fictional placeholders by default, for example <服务A>、<版本>、<制品标识>. When there is no actual evidence, output "not verified" and the next step to obtain evidence.
Private Information and Intermediate Data
- Use only the release information the customer proactively provides in the current request; do not read company knowledge bases, private repositories, accounts, historical release records, or local private configurations to complete the checklist.
- Do not request, record, or echo secrets, tokens, passwords, sessions, customer data, internal domains, or production access addresses. If the input contains such values, replace them with
<已提供的敏感值>。 - Intermediate information in the draft plan and reasoning is used only for the current session; if the customer requests that it be persisted, they should choose a controlled location and retention period themselves, and desensitize it first.
Logs and Completion Receipt
The final reply must provide:
- The release elements covered (version, branch, artifact, configuration, dependencies, testing, approval, rollback, gradual rollout, post-release verification);
- The count of precheck gate statuses (passed, blocked, to be confirmed) and the reason for each blocked or to-be-confirmed item;
- The evidence used and the items not actually verified;
- The recommended next steps, for example completing artifact verification, confirming stop thresholds, or obtaining approval.
Do not describe "checklist generated" as "already released" or "production environment verified".
Acceptance
Before delivery, perform a forward check: choose any gradual rollout batch from the output and confirm that it simultaneously contains scope, observation items, pass conditions or to-be-confirmed markers, stop actions, and an owner; and confirm that every precheck gate has evidence or a clearly identified gap. If any item is missing, return to the corresponding process step to complete it.