Scope of Use and Preparation
This skill can be installed independently; the necessary methods are all in this file and do not depend on the author's machine or other skills. First read the target project specifications and confirm the target repository/workspace, version, user results, and allowed changes; the reference repository is read-only. When there are no project rules, read the actual README, scripts, and source code to derive the entry points.
Execute with the tools currently available and authorized: if an independent agent is missing, use a new session/manual review or self-check from separate perspectives, and note the actual review method; if a browser/real API is missing, complete the executable parts and hand off the uncovered acceptance, and do not pretend that independent review, GUI, or real services passed. The project's original runtime environment is still required; do not bind to a model vendor or specific plugin.
For complex tasks, you may use assets/task-record.md to save necessary facts; for simple tasks, record the results directly and do not mechanically add process.
Suitable for tasks that have already requested a release or are preparing a specific version delivery. Building a release pipeline is not the default work of this process and is not bound to Tauri, Electron, npm, or cloud vendors.
Prepare Reviewable Results
Confirm the release method, target platform/channel, version source, current commit, existing workflow, and authorization boundaries. After reading the actual diff for this release, write concise notes; explain the changes users can observe, and performance figures must have a measurement basis.
Check the applicable version images, tags, lockfiles, notes, and artifact names. Update along existing conventions and do not let CI guess the version temporarily. When the user requests that notes be reviewed first, first complete the specific notes and reviewable changes, then wait at the specified release step; do not repeatedly request confirmation for ordinary authorized actions.
Observe the Actual Release
After the relevant local checks pass, execute the currently authorized commit, tag, CI, or release method. Observe the real runtime results of the corresponding version, distinguishing success, failure, cancellation, still running, and not triggered. A successful push must not be passed off as a successful release.
On failure, verify the cause and residual state based on logs. Reruns must be bounded and must confirm they will not duplicate the release or overwrite the wrong version; when the result is unknown, first query the release status. Do not rebuild unrelated configuration under the pretext of fixing the pipeline.
Accept the Artifacts Ordinary Users Receive
Obtain the actual artifact from the currently authorized channel and record its version, source identity, file digest, or supply chain metadata. Check the target platform and entry point; do not merely run the source directory instead of the release package.
Perform relevant acceptance by artifact type:
- CLI/package: install or unpack in an isolated directory, run the real bin/export interface, and observe one actual task and the exit status.
- Desktop: cover installation, first launch, and this change's path on platforms where it can be executed; when there are upgrade changes, add the corresponding state preservation from the old version to the new version.
- Service/website: check the actual deployment identity, call the deployment entry point, and verify this change's results and necessary error paths.
When target OS, GUI, signing, or real service resources are unavailable, limit the coverage scope and provide accurate manual actions and pass conditions. A correct digest only proves identity or integrity and cannot replace functional acceptance.
Delivery
Provide the version, channel/artifact location, corresponding verification, and failed or unverified parts. If only local build was performed, report the local build; if the actual release succeeded but the target platform was not accepted, explain them separately.
Maintain a bounded approach to recovery: which task files can be rolled back, and which external releases require an established retraction/replacement process. You cannot promise to undo arbitrary user data or third-party operations.