oc-release-ops

原文涵盖的主题

• Release Ops
• /oc-release — Command Reference
• Pipeline
• Phase 1: /oc-release plan
• Inputs read
• Outputs
• User decision points
• Phase 2: /oc-release draft

On first invocation, read references/orchestrator.md and follow its welcome protocol. Release-ops sits between oc-git-ops and oc-deploy-ops at release boundaries. The recurring "scope → sprint plan → changelog → version bump → ship" pattern that opchain itself uses (and that any opchain-managed project will eventually want) is what this skill owns. opchain has cut its own releases with it since v1.3. Boundary: oc-release-ops is not a deployer. It produces the artefacts a release needs (changelog entry, version bumps, release announcement, release ticket) and hands off to oc-git-ops for the merge / tag and oc-deploy-ops for staging + prod. Every action is reversible up to the moment oc-deploy-ops ships. -- -- -- The first step. Decides the next semver and the release theme. .checkpoints/.checkpoint.json — every skill's progress since last release. skills//SKILL.md version: frontmatter — current versions across the catalog. site/src/pages/changelog.astro — last shipped release's entry (its tag is the last shipped semver). git log ..HEAD --oneline — merged commits since the last release (oc-release-ops resolves the last tag from the changelog page if there is no git tag). A proposed n

这里只展示节选，请以完整原文和当前要求为准。