Publish

You are the release manager for oh-my-opencode. Execute the FULL publish workflow from start to finish.

CRITICAL: PUBLISH IS SHIP-ONLY — GO STRAIGHT TO THE WORKFLOW

origin/dev is already gated: every PR and push ran CI (test/typecheck/codex-compatibility on 3 OSes), and the publish workflow re-runs those same gates before anything is published.

• NEVER run `/pre-publish-review`, `/review-work`, or any code re-review as part of a publish request. Those run ONLY when the user explicitly asks for a review.
• NEVER "fix" code, open PRs, or enter fix-and-re-audit loops during a publish. If the workflow fails or something looks broken, report it and STOP — a publish is the wrong place to repair the tree.
• A publish request with a bump type goes from Step 0 to Step 3 (trigger) in minutes. The only human-scale work is release notes, drafted while CI runs.

CRITICAL: FULL WORKFLOW MEANS THREE RELEASE SURFACES

Publishing is complete only after all release surfaces are verified:

The publish workflow must not be reported complete while any of oh-my-opencode, oh-my-openagent, lazycodex-ai, or code-yeongyu/lazycodex verification is unresolved.

CRITICAL: FULL WORKFLOW MEANS DISCORD TOO

Publishing is not complete until the Discord release announcement has been attempted.

• DO NOT stop after creating the GitHub release.
• DO NOT stop after drafting or applying release notes.
• DO NOT wait for a second user acknowledgement if the user already confirmed the publish.
• After the release notes are finalized, immediately run Step 7.5 and post to Discord.
• If Discord posting fails after authentication/retry, report the failure clearly and continue the remaining verification steps. A skipped Discord step is a workflow failure.

CRITICAL: NO EARLY TURN-END AFTER TRIGGER (COMPLETION CONTRACT)

Once gh workflow run publish succeeds, the publish is NOT done. A prior session forgot this: it triggered the workflow and ended its turn, leaving the release unverified, the enhanced summary unwritten, and the Discord announcement unsent. That mistake is why this section exists.

After Step 3 (trigger), you MUST drive the run to a terminal conclusion AND complete every post-trigger step before ending your turn. You may NOT end the turn, hand off, or stop for the day while ANY of these is unresolved:

1. Run conclusion — gh run view <id> --json conclusion must return success (poll while drafting notes; never sleep idle).
2. Release exists — Step 5: gh release view v${NEW_VERSION} resolves.
3. Enhanced summary applied — Step 6 + Step 7: draft (mandatory for patch/minor/major) AND gh release edit --notes-file applied. "Patch is optional" is wrong; patch summaries are MANDATORY.
4. Discord announced — Step 7.5: agent-discordbot message send attempted; either a message id is recorded OR a clear failure is reported to the user. A skipped Discord step is a workflow failure.
5. npm verified — Step 8: npm view oh-my-opencode version (and oh-my-openagent, lazycodex-ai) shows ${NEW_VERSION}.

Only after all five are green may you end the turn. If the run fails, run gh run view <id> --log-failed, report it, and STOP (do not repair the tree mid-publish). If a post-trigger step fails for an external reason (npm propagation, Discord auth), report it clearly and continue the remaining steps — do not let one failure abort the rest.

This contract applies to the slash-command copies (.agents/command/publish.md, .opencode/command/publish.md) too; they are kept byte-identical to this skill per the .agents/AGENTS.md drift rule.

CRITICAL: ARGUMENT REQUIREMENT

You MUST receive one release selector from the user. Valid options:

• patch: Bug fixes, backward-compatible (1.1.7 → 1.1.8)
• minor: New features, backward-compatible (1.1.7 → 1.2.0)
• major: Breaking changes (1.1.7 → 2.0.0)
• An explicit valid semantic version, including a prerelease such as 5.0.0-beta.9

If the user did not provide a release selector, STOP IMMEDIATELY and ask:

"To proceed with deployment, specify patch, minor, major, or an explicit semantic version such as 5.0.0-beta.9."

Reject any other value. Do not infer or repair malformed versions.

STEP 0: REGISTER TODO LIST (MANDATORY FIRST ACTION)

Before doing ANYTHING else, create a detailed todo list using TodoWrite:

[
  { "id": "confirm-release-input", "content": "Confirm release selector with user (patch/minor/major or explicit semver)", "status": "in_progress", "priority": "high" },
  { "id": "check-uncommitted", "content": "Check for uncommitted changes and commit if needed", "status": "pending", "priority": "high" },
  { "id": "sync-remote", "content": "Sync with remote (pull --rebase && push if unpushed commits)", "status": "pending", "priority": "high" },
  { "id": "run-workflow", "content": "Trigger GitHub Actions publish workflow", "status": "pending", "priority": "high" },
  { "id": "wait-workflow", "content": "Wait for workflow completion (poll every 30s)", "status": "pending", "priority": "high" },
  { "id": "verify-and-preview", "content": "Verify release created + preview auto-generated changelog & contributor thanks", "status": "pending", "priority": "high" },
  { "id": "draft-summary", "content": "Draft enhanced release summary (mandatory for all release types)", "status": "pending", "priority": "high" },
  { "id": "apply-summary", "content": "Prepend enhanced summary to release", "status": "pending", "priority": "high" },
  { "id": "discord-announce", "content": "MANDATORY: post release announcement to Discord channel immediately after release notes are finalized", "status": "pending", "priority": "high" },
  { "id": "verify-npm", "content": "Verify npm package published successfully", "status": "pending", "priority": "high" },
  { "id": "verify-lazycodex", "content": "Verify lazycodex-ai publish, Codex plugin metadata version stamp, and code-yeongyu/lazycodex release/sync", "status": "pending", "priority": "high" },
  { "id": "verify-platform-binaries", "content": "Spot-check platform binary packages on npm", "status": "pending", "priority": "high" },
  { "id": "final-confirmation", "content": "Final confirmation to user with links", "status": "pending", "priority": "low" }
]

Mark each todo as `in_progress` when starting, `completed` when done. ONE AT A TIME.

STEP 1: CONFIRM AND CLASSIFY THE RELEASE SELECTOR

If the user already supplied the selector in the command argument or message, that IS the confirmation. Parse it exactly once:

RELEASE_INPUT="${ARGUMENTS}"
if [[ "$RELEASE_INPUT" =~ ^(patch|minor|major)$ ]]; then
  RELEASE_KIND=bump
elif [[ "$RELEASE_INPUT" =~ ^([0-9]+\.){2}[0-9]+(-[0-9A-Za-z]+(\.[0-9A-Za-z]+)*)?$ ]]; then
  RELEASE_KIND=version
else
  echo "Invalid release selector: $RELEASE_INPUT" >&2
  exit 1
fi

Only ask and wait when no selector was provided.

STEP 2: CHECK UNCOMMITTED CHANGES

Run: git status --porcelain

• If there are uncommitted changes, warn user and ask if they want to commit first
• If clean, proceed

STEP 2.5: SYNC WITH REMOTE (MANDATORY)

Check if there are unpushed commits:

git log @{u}..HEAD --oneline