release-plugin

Files (2)

• SKILL.md
• openai.yaml · agents/

SKILL.md (first lines)

# Release Plugin

Operate only on the current Workflow plugin repository. The current explicit invocation authorizes one complete release lifecycle, including version selection and preparation; do not ask for another approval for that work.

1. Confirm `package.json`, `.cursor-plugin/plugin.json`, `targets/codex/.codex-plugin/plugin.json`, `targets/opencode/.opencode-plugin/plugin.json`, `targets/agent-plugins/plugin.json`, and `scripts/plugin-github-release.mjs` exist. The release script is authoritative for authenticated GitHub access, expected origin, commit identity, synchronized `main`, and tag or release state. Inspect those manually only to choose the version, read retained retry state, or diagnose a failure. Inspect `.build/releases` for retained retry state first. An exact partial release must resume with its existing version through the release script; never bump to evade a conflict. Stop on ambiguous state.
2. Inspect Unreleased notes and the actual changes since the latest published version, including non-ignored uncommitted files. Choose SemVer by the strongest user-visible impact: major for incompatible behavior or removed public capabilities, minor for compatible additions, patch for compatible fixes or documentation/maintenance alone. Do not infer impact solely from commit labels. Explain the chosen version briefly and proceed. Reuse an already prepared, appropriate, unused version; do not bump twice. If there are no new changes, run the script to verify the existing exact release instead of manufacturing a new one.
3. For a new release, check that the chosen tag and release are unused. An exact partial release resumes its existing version, and an existing exact release is verified without requiring a new unused tag. Update the version consistently in `package.json` and all four source manifests, plus a lockfile if present. The OpenCode manifest's `opencodeCompatibility` stays on the targeted OpenCode release until that target is intentionally changed. Update current installation examples and maintain accurate Unreleased notes; preserve historical entries. The script performs the changelog cut. Do not alter product code to force a release check to pass. Leave preparation edits visible if validation fails and describe them for the next invocation.
4. Run exactly `npm run release:plugin` from the repository root. The script validates all non-ignored tracked and untracked changes, cuts the changelog, runs the complete release gate, creates at most one `Release v{version}` commit when necessary, creates the matching lightweight tag, atomically pushes `main` and the tag, creates the GitHub Release, and verifies its downloaded assets. It remains the sole implementation of these publication effects.
5. Report the version and selection reason, commit and whether it was created, tag, atomic-push result, each host archive hash and file count, provenance receipt, release-gate result, GitHub URL, and read-back verification. On failure, stop and report every blocker, preparation edits, and exact retained retry state. A later retry requires a new explicit invocation.

Never deploy or install the plugin, restart a host, overwrite assets, use `--clobber`, delete remote state, reset history, force-push, or hide a partial state. The script's path, secret, version, changelog, source-drift, and remote-state checks remain mandatory; never bypass a failed gate. An existing exact downloaded-and-verified release requires no mutation.

From geldmacher/workflow, MIT.

More from geldmacher/workflow