publish
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>. Triggers: publish, release, deploy, npm publish.
Profile →npx skills add code-yeongyu/oh-my-openagent --skill publish --agent claude-code
Same command for any agent — swap --agent for codex, cursor, copilot.
Weekly change comes from our own snapshots, not the repository page — it measures attention, not adoption.
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 i
- CRITICAL: PUBLISH IS SHIP-ONLY — GO STRAIGHT TO THE WORKFLOW
- CRITICAL: FULL WORKFLOW MEANS THREE RELEASE SURFACES
- CRITICAL: FULL WORKFLOW MEANS DISCORD TOO
- CRITICAL: NO EARLY TURN-END AFTER TRIGGER (COMPLETION CONTRACT)
- CRITICAL: ARGUMENT REQUIREMENT
- STEP 0: REGISTER TODO LIST (MANDATORY FIRST ACTION)
- STEP 1: CONFIRM BUMP TYPE
- STEP 2: CHECK UNCOMMITTED CHANGES
- STEP 2.5: SYNC WITH REMOTE (MANDATORY)
- STEP 3: TRIGGER GITHUB ACTIONS WORKFLOW
- STEP 4: WAIT FOR WORKFLOW COMPLETION
- STEP 5: VERIFY RELEASE & PREVIEW AUTO-GENERATED CONTENT
- STEP 6: DRAFT ENHANCED RELEASE SUMMARY
- LAST RELEASE BEFORE THE OMO NATIVE CLI PUBLIC RELEASE
git log @{u}..HEAD --oneline
git pull --rebase && git push
gh workflow run publish -f bump={bump_type}
gh run list --workflow=publish --limit=1 --json databaseId,status --jq '.[0]'
gh run view {run_id} --json status,conclusion,jobs --jq '{status, conclusion, stage: ([.jobs[] | select(.status=="in_progress") | .name] | join(", "))}'
gh run view {run_id} --log-failed
Pull latest (workflow committed version bump)
git pull --rebase
Verify release exists on GitHub
gh release view "v${NEW_VERSION}" --json tagName,url --jq '{tag: .tagName, url: .url}'What does the publish skill do?
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>. Triggers: publish, release, deploy, npm publish.
How do I install it?
Run `npx skills add code-yeongyu/oh-my-openagent --skill publish --agent claude-code` — it drops the skill into your project so the agent can pick it up. Swap the --agent value for codex, cursor or copilot if you use one of those.
Where does this skill come from?
From code-yeongyu/oh-my-openagent, a repository with 67,209 stars. We read it straight from the repository tree rather than a submitted listing, so what you see here is what is actually published.
Is a popular skill a good skill?
Not necessarily. Stars measure attention, not adoption — a repository can trend for a week and be abandoned. That is why we show the weekly change from our own snapshots next to the total, instead of a single flattering number.