Publish oh-my-opencode to npm by triggering the GitHub Actions publish workflow and verifying its artifacts. Ship-only: never runs pre-publish-review or re-reviews merged code unless the user explicit
1---2name: publish3description: Publish oh-my-opencode to npm by triggering the GitHub Actions publish workflow and verifying its artifacts…4---56# .agents/skills/publish/SKILL.md
P
SKILL.mdAgent skill
Transport
File
Status
Listed
SKILL.md
Install
The skill file stays in the publisher's repository.
Paste the copied command in a terminal. It installs this SKILL.md into that agent.
shterminal
1npx skills add code-yeongyu/oh-my-openagent --skill publish -a cursor -y
Paste the copied command in a terminal. It installs this SKILL.md into that agent.
Publish oh-my-opencode to npm by triggering the GitHub Actions publish workflow and verifying its artifacts. Ship-only: never runs pre-publish-review or re-reviews merged code unless the user explicitly asks. Argument: <patch|minor|major|explicit-semver>. Triggers: publish, release, deploy, npm publish.
Download .agents/skills/publish/SKILL.md from the publisher, or copy the path and open the repository. PlugMCP lists the skill and does not host the file.
Where does publish live?
The publisher keeps it at https://github.com/code-yeongyu/oh-my-openagent.
Which agents can use publish?
Claude, Cursor, Codex, and Grok Build can read a SKILL.md you add from the publisher's repository. Grok Bot installs it when you send the skill's GitHub folder link in a chat.
From the publisher
SKILL.md
name
publish
description
Publish oh-my-opencode to npm by triggering the GitHub Actions publish workflow and verifying its artifacts. Ship-only: never runs pre-publish-review or re-reviews merged code unless the user explicitly asks. Argument: <patch|minor|major|explicit-semver>. Triggers: publish, release, deploy, npm 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:
Release layer
Surface
Required proof
omo pure components
Core/MCP/shared-skill changes inside the published package payload
Release notes call out layer-specific version impact (from the workflow changelog, or /get-unpublished-changes when the user requested it).
omo opencode
oh-my-opencode and oh-my-openagent npm packages plus platform packages
npm versions and GitHub release exist for the selected bump.
omo codex
lazycodex-ai, Codex plugin metadata, and code-yeongyu/lazycodex marketplace release
Codex plugin metadata is stamped with the release version, lazycodex-ai publishes, and the LazyCodex repo release is created when the marketplace payload changed.
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:
Run conclusion — gh run view <id> --json conclusion must return success (poll while drafting notes; never sleep idle).
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.
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.
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:
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
If there are unpushed commits, you MUST sync before triggering workflow:
git pull --rebase && git push
This ensures the GitHub Actions workflow runs on the latest code including all local commits.
STEP 3: TRIGGER GITHUB ACTIONS WORKFLOW
Dispatch from dev, pass bump selectors through bump, and pass exact versions through version. The required bump input remains patch for explicit-version dispatches but is ignored by the workflow because version takes precedence.
if [ "$RELEASE_KIND" = bump ]; then
RUN_URL="$(gh workflow run publish.yml --ref dev -f "bump=${RELEASE_INPUT}")"
else
RUN_URL="$(gh workflow run publish.yml --ref dev -f bump=patch -f "version=${RELEASE_INPUT}")"
fi
if ! [[ "$RUN_URL" =~ ^https://github.com/code-yeongyu/oh-my-openagent/actions/runs/[0-9]+$ ]]; then
echo "Publish dispatch did not return an exact workflow run URL: $RUN_URL" >&2
exit 1
fi
RUN_ID="${RUN_URL##*/}"
if ! [[ "$RUN_ID" =~ ^[0-9]+$ ]]; then
echo "Publish dispatch returned an invalid run ID: $RUN_ID" >&2
exit 1
fi
gh run view "${RUN_ID}" --json databaseId,status,url --jq '{databaseId,status,url}'
The returned run ID owns this release attempt. Never replace it with a latest-run lookup.
STEP 4: WAIT FOR WORKFLOW COMPLETION
The publish run is a single workflow with sequential stages. Expected timeline (from recent real runs, ~30 min total):
Stage (job)
What it does
Typical
test / typecheck / codex-compatibility (3 OS)
Re-runs the CI gates on the release source
4–8 min (Windows is the long pole)
prepare-release-state
Stamps versions, opens + auto-merges the release: vX.Y.Z PR, waits for that PR's required CI checks
10–15 min (dominant stage)
publish-platform (build + publish, 12 targets)
Builds and publishes both platform package families
IMPORTANT: Use polling loop, NOT sleep commands. Use the waiting time to draft the enhanced release summary (Step 6) — do not sit idle, and do not start any review activity.
Release notes are written BEFORE the release, not after.
The release body is extracted from the CHANGELOG.md section for this version. Add the user-facing notes as changes/unreleased/<pr-number>.md fragments (one per PR, named for the PR) and land them before dispatching /publish; release-state preparation
stamps that heading into ## [<version>] - <UTC date> and commits it with the release state, so the
published commit already carries its own notes.
Preview exactly what the release body will be:
bun run script/generate-changelog.ts > /tmp/contributors.md
bun run script/print-release-notes.ts "${NEW_VERSION}" /tmp/contributors.md
This is the exact body the release will publish: the assembled fragments,
then contributor thank-yous for non-team contributors, then the install footer.
Both steps are fail-closed: an absent, empty, or duplicated section aborts the release instead of
publishing blank notes, and re-stamping a version that already has a section is refused.
If changes/unreleased/ holds no fragments, STOP and write them first — the release cannot proceed.
APPROVAL GATE (single, binary): The user's initial publish request with a named bump type IS the only approval this workflow requires. Do NOT wait for a separate acknowledgement here. Present the preview, then IMMEDIATELY proceed to Step 6. The only exception: if the user explicitly said "let me review the changelog before you continue" (or equivalent), stop and wait. Otherwise continue without ending the turn.
STEP 6: DRAFT ENHANCED RELEASE SUMMARY
Release Type
Action
patch
MANDATORY. Draft a concise bug-fix / change summary. Do NOT proceed without one.
minor
MANDATORY. Draft a concise feature summary. Do NOT proceed without one.
major
MANDATORY. Draft a full release narrative with migration notes if applicable. Do NOT proceed without one.
LAST RELEASE BEFORE THE OMO NATIVE CLI PUBLIC RELEASE
When the user identifies this as the final release before the OmO Native CLI public release, the GitHub summary MUST begin with this dedicated heading and the Discord announcement MUST repeat it as a dedicated heading immediately after @here:
## LAST RELEASE BEFORE THE OMO NATIVE CLI PUBLIC RELEASE
What You're Writing (and What You're NOT)
You are writing the headline layer — a product announcement that sits ABOVE the auto-generated commit log. Think "release blog post", not "git log".
Token refresh is now automatic and seamless. Sessions no longer expire mid-task — the system silently rotates credentials in the background. If you've been frustrated by random logouts, this release fixes that.
Rules are now cached by file modification time. If your project has 50+ rule files, you'll notice startup is noticeably faster — we measured a 3x improvement in our test suite.
Drafting Process
Analyze the commit list from Step 5's preview. Identify 2-5 themes that matter to users.
Write the summary to /tmp/release-summary-v${NEW_VERSION}.md.
Present the draft to the user for review and approval before applying.
# Write your draft here
cat > /tmp/release-summary-v${NEW_VERSION}.md << 'SUMMARY_EOF'
{your_enhanced_summary}
SUMMARY_EOF
cat /tmp/release-summary-v${NEW_VERSION}.md
APPROVAL GATE (same single gate): The initial publish confirmation covers this step too. Present the draft, then IMMEDIATELY proceed to Step 7 (apply) and Step 7.5 (Discord). Do NOT stop to wait for approval unless the user explicitly requested a release-note review hold before the publish started. The Discord announcement (Step 7.5) is mandatory and must not be blocked by a review hold that was never requested.
STEP 7: APPLY ENHANCED SUMMARY TO RELEASE
This step is MANDATORY. The enhanced summary from Step 6 must always be applied.
┌─────────────────────────────────────┐
│ Enhanced Summary (from Step 6) │ ← You wrote this
│ - Theme-based, user-impact focused │
├─────────────────────────────────────┤
│ --- (separator) │
├─────────────────────────────────────┤
│ Auto-generated Commit Changelog │ ← Workflow wrote this
│ - feat/fix/refactor grouped │
│ - Contributor thank-you messages │
└─────────────────────────────────────┘
After the release notes are finalized, post them to the Discord channel. This step is mandatory for every publish run.
Never skip this step because the release summary was awaiting approval. If the user already confirmed the publish, continue through Discord before stopping.
Read recent messages in the channel to match the existing announcement style:
RELEASE_BOT_ID=1486173823354146917
agent-discordbot message list 1454708427392680067 --bot "$RELEASE_BOT_ID" --limit 5
If agent-discordbot is unavailable or unauthorized, stop and report that the release bot token path failed. Only then may a human decide whether to use agent-discord.
Post the release announcement to channel 1454708427392680067 matching the style of previous announcements. The message should follow this structure:
If the message fails to send, warn the user and continue — do NOT block the publish workflow on Discord errors.
STEP 8: VERIFY NPM PUBLICATION
Poll npm registry until the new version appears:
npm view oh-my-opencode version
Compare with expected version. If not matching after 2 minutes, warn user about npm propagation delay.
STEP 8.5: SPOT-CHECK PLATFORM BINARY PACKAGES
Platform packages are built and published by the publish-platform jobs INSIDE the same publish run — there is no separate workflow to wait for, and publish-main already refuses to publish unless matching platform binaries exist. Spot-check a representative sample:
for PKG in oh-my-opencode-darwin-arm64 oh-my-openagent-linux-x64 oh-my-opencode-windows-x64; do
npm view "$PKG" version
done
Each should show ${NEW_VERSION}. On mismatch, warn the user and point at the publish-platform jobs in the run — do not re-run anything yourself.
Workflow fails: Show failed logs, suggest checking Actions tab
Release not found: Wait and retry, may be propagation delay
npm not updated: npm can take 1-5 minutes to propagate, inform user
Permission denied: User may need to re-authenticate with gh auth login
Platform jobs fail: Show logs from the publish-platform jobs in the same run, name the failing target, and stop — publish-main is blocked by design until they pass