oc-release-ops

# Release Ops

**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. v1.3 dogfoods this skill for its own release.

**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.

---

## /oc-release — Command Reference

```
RELEASE OPS COMMANDS
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  END-TO-END
  /oc-release                Show this menu
  /oc-release ship           Run the full pipeline: plan → draft → bump → announce → hand off

  STEPWISE
  /oc-release plan           Propose the next semver from changelog gaps + sprint outputs
  /oc-release draft          Draft the /changelog entry from sprint checkpoints + merged PRs
  /oc-release bump           Bump every skill version + styleguide badge atomically
  /oc-release announce       Compose homepage release-pill + release ticket + announcement copy

  UTILITIES
  /oc-release status         Where in the pipeline am I?
  /oc-release verify         Pre-ship sanity gate (tests / catalog / validator / build)
  /oc-release rollback       Revert the last bump if not yet shipped

  SESSION
  /checkpoint             Show oc-release-ops checkpoint
  /checkpoint show        Full checkpoint JSON
  /checkpoint reset       Archive and restart

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  Type any command to begin. /oc-release to see this again.
```

---

## Pipeline

```
RELEASE TRIGGER
       │
       ▼
┌───────────────┐  reads sprint checkpoints, /changelog gaps, merged PRs since
│   /oc-release    │  the last release; proposes next semver per the decision tree
│   plan        │  in references/semver-decisions.md.
└───────┬───────┘
        │
        ▼
┌───────────────┐  composes the /changelog entry from sprint deliverables +
│   /oc-release    │  PR titles + skill-version diffs; produces draft markdown
│   draft       │  ready for human review.
└───────┬───────┘
        │
        ▼
┌───────────────┐  rewrites every skills/<id>/SKILL.md `version:` field +
│   /oc-release    │  styleguide badge; updates homepage release-pill href and
│   bump        │  copy; commits as one atomic change.
└───────┬───────┘
        │
        ▼
┌───────────────┐  composes release announcement (release ticket via PM-MCP +
│   /oc-release    │  internal announcement copy + external blog/social copy);
│   announce    │  per oc-integrations-engineer pm-mcp-protocol.md.
└───────┬───────┘
        │
        ▼
┌───────────────┐  invokes /oc-release verify → npm run prebuild gates;
│   /oc-release    │  hands the branch to oc-git-ops /oc-git-sync and tells the user
│   ship        │  to run /oc-deploy staging → /oc-deploy prod.
└───────────────┘
```

---

## Phase 1: `/oc-release plan`

The first step. Decides the next semver and the release theme.

### Inputs read

- `.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 <last-release-tag>..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).

### Outputs

- A proposed next semver per `references/semver-decisions.md`. Patch / minor /
  major decided from the kinds of work merged: bug-fix only → patch; backward-
  compatible feature work → minor; breaking changes / new skill → minor with
  release-note callout; auth/protocol/spec breakages → major.
- A proposed release theme name (e.g. v1.3 = "Runtime PM, real platforms,
  automated releases").
- A list of headline items, ranked by surface impact.
- A proposed list of skill versions to bump (default: all of them, in lockstep
  with the release version, per the v1.2 precedent).

### User decision points

- Approve / override the proposed semver.
- Approve / edit the theme name.
- Approve the headline-item ranking (this drives `/oc-release draft` order).

Write checkpoint: phase `plan-approved`.

---

## Phase 2: `/oc-release draft`

Produce a `/changelog` entry ready for review.

### Composition rules

- Mirror the structure of existing `/changelog` entries (summary lede →
  "What's new" → "Two new scenarios" → "Configuration" → "Compatibility" →
  "Security posture") for stylistic consistency.
- Each "What's new" bullet leads with **the user-visible change**, not the
  implementation detail. "oc-git-ops now reads ticket state via real MCP tool
  names" beats "Replaced placeholder mcp.<provider>.<verb> patterns."
- Every scenario shipped in the release gets a one-paragraph callout under
  "Scenarios" with a deep link to `/demo#<id>`.
- "Configuration" describes any new `.opchain/*.yaml` keys or env vars.
- "Compatibility" is required and explicit. Either "back-compatible with vX.Y;
  no migration required" OR a list of migration steps with a deadline.
- "Security posture" — required when the release touches auth / regulated
  flows / new external surfaces. Optional otherwise.

### File output

The draft is appended to `site/src/pages/changelog.astro` as a new
`<section class="release release--current">`, with the previous current
release demoted to `<section class="release">` and `rel-tag rel-tag--past`.

### Validation

`/oc-release verify` (run automatically after draft) gates:
- Each "What's new" bullet ≤ 280 characters (changelog page reading rhythm).
- Each scenario callout is ≤ 600 characters.
- "Comp