lov-release-via-cicd

CI/CD Release

Configure or run an existing project release pipeline, and read back artifacts and the actual live status.

Triggers

Activate when

• "Configure or run an existing project release pipeline, and read back artifacts and the actual live status."
• “Set up or run a verified CI/CD release.”

Do not activate when

• Only querying this Skill's documentation, or requesting tasks unrelated to the above results; does not perform actual business operations.
• When the user only wants a preview or review, do not enter the modify, commit, or publish branch.

Execution boundary

A natural language request is enough to trigger it; no legacy slash path, parameter interpolation, or designated assistant is needed. Clearly parse the project, target files, options, and output location in the current request; use the file, search, CLI, and browser capabilities actually provided by the current host. Project dependency versions and external APIs are verified at execution time; do not assume the examples are the current configuration. Bundled scripts are resolved from the Skill root, and business files are resolved from the target project root. Read the current state first, and protect existing uncommitted content and the staging area of other tasks. Analysis and preview requests remain read-only; modification, commit, push, deployment, and release each execute according to the explicit scope of the current request. Do not bypass protections, automatically send messages, forcibly terminate user processes, or seize the foreground. On failure, retain the diagnosable raw error.

Workflow

1. Distinguish setup, publish, setup+publish, local, ci, ci-auto, and status; audit or configuration alone does not authorize publishing. Read the project language, package manager, version, CHANGELOG, branch, remote, protection rules, and existing workflows.

2. Keep the current release method; fix configuration gaps first based on project facts. Migrating semantic-release to changesets is a separate action, implemented only when the user requests it; do not unconditionally install changesets.

3. Before publishing, review the target diff and staged files, and commit only the files involved in this release. Do not automatically run git add -A in a dirty workspace, do not forcibly switch to the main branch, and do not automatically swallow commit failures or overwrite other tasks.

4. By default, increment by the current version's patch, keeping 0.x at 0.x; handle breaking upgrades as specified by the user. Synchronize all actual version sources, the lockfile, and the CHANGELOG; generate release notes from verified changes, and do not fabricate history.

5. Branch releases follow protection and PR processes, using a separate worktree when necessary; do not bypass review, hooks, signing, or non-fast-forward protection. Do not rewrite already published tags; fix omissions with a patch version.

6. For Node/monorepo, generate a changeset based on the configuration and run version; for Shell or other projects, handle it according to existing version files and tag rules. Pushing tags and triggering workflows are executed only within the target scope authorized for release.

7. Verify CI parameters, actions, and signing configuration against the current official and existing project implementations. For desktop or Tauri projects, fully read references/tauri-release-workflow.md; for other projects, read references/general-release-playbooks.md.

8. Wait for the final status of the triggered run, recording the specific run ID, commit, tag, and failure logs; for longer processes, use host wait or monitoring tools, and do not treat queuing as completion.

9. Read back the Release and attachments; for desktop, verify signing, notarization, the App inside the installer, and the update chain; when a regional mirror is needed, synchronize only after the primary release and verification pass, and do not let a mirror failure mask the primary artifact status.

10. Only send messages to or close related issues when explicitly authorized; the release itself does not automatically authorize external comments. Report the actual results of each layer: configuration, build, release, website/store, and installation verification.

Composition

Before execution, read capability composition, and hand off between adjacent capabilities according to explicit artifacts.

Runtime context (shared)

Before running, read this package's skill.yaml and Profile contract. The priority order is the current request, project context, this Skill records, shared preferences, brand/user Profile, and safe defaults. Only read declared fields; a host without a dedicated runtime can use scripts/profile_store.py to read the shared Profile. If configuration is missing, ask only one question that affects the outcome. Values the user explicitly asks to keep long-term are written atomically through that script, and report the actual path; do not save inferences, credentials, or materials from other tasks.

General feedback loop

When the user raises modification feedback during a Skill-driven task, before continuing with the current artifact you must do the following:

1. First determine whether the feedback is task-specific(this time only) or reusable(reusable across tasks).
2. task-specific Only modify the current task, not the Skill.
3. reusable First determine the scope: for domain rules, first update the corresponding canonical Skill; for rules that apply to all Skills, first update the shared specification.
4. After completing the rule update, versioning, lint, and distribution verification, then apply the modification to the current task.
5. reusable The modification invalidates previous "confirm," "continue," and "send it" statements; after completing the current artifact modification and read-back, you must stop and wait for the user's next instruction, and must not automatically proceed to publishing, submitting, or other external writes.