一键导入
publish
Publish oh-my-opencode to npm via GitHub Actions workflow. Argument: <patch|minor|major>. Triggers: publish, release, deploy, npm publish.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Publish oh-my-opencode to npm via GitHub Actions workflow. Argument: <patch|minor|major>. Triggers: publish, release, deploy, npm publish.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Codex-only team orchestration: run a named team of cooperating Codex threads with durable, script-managed state. MUST USE when the user asks Codex to create, run, coordinate, inspect, archive, or delete a team of threads/sessions, or to work on something as a team in parallel. The main session is always the leader; members are defined by a concrete part, ownership area, or perspective - never a vague job role; a bundled cross-platform script writes the .omo/teams state plus an auto-generated member field manual. Use a team when the work is not perfectly isolated but parallelizing helps, or when a task still needs exploration under a clear goal; use plain subagents when scope is perfectly isolated or the goal is ambiguous. Triggers: team mode, teammode, make a team, run as a team, team of agents, coordinate threads, parallel Codex threads, archive the team, delete the team.
QA the omo Codex Light edition (lazycodex / packages/omo-codex) itself, in strict isolation so ONLY our plugin is exercised, never the user's real ~/.codex. The first-party method drives the real `codex app-server` against an isolated CODEX_HOME plus a LOCAL mock model (no real API call), and proves a plugin hook fired by asserting hook/started + hook/completed notifications. Also: isolated install verification, per-component hook probes, a tmux TUI smoke, and runtime log observation (RUST_LOG / logs SQLite / /debug-config). Ships tested helper scripts each with a --self-test. Use whenever someone changes anything under packages/omo-codex or wants to QA, smoke-test, verify, or debug the Codex plugin, its hooks/components, the installer/config.toml, the app-server flow, or the Codex TUI. Triggers: codex qa, qa codex, codex-qa, test codex plugin, verify codex hook, codex app-server, lazycodex qa, isolated CODEX_HOME, prove codex hook fired, codex tui test.
QA opencode itself, per case: verify the CLI/terminal (opencode run, db, serve, export), prove a specific plugin hook/action/event fired via the SSE event stream, smoke-test the TUI under tmux, and investigate sessions in opencode's SQLite DB by id, title/name, or message text. Ships tested helper scripts (each with a --self-test) plus per-domain references. Use whenever someone wants to QA, smoke-test, verify, or debug opencode's CLI, HTTP server, plugin hooks/events, or TUI, or to find/inspect opencode sessions in the database. Triggers: opencode qa, qa opencode, test opencode, verify opencode hook, opencode session db, find opencode session by id/name/text, opencode tui test, opencode server health, opencode event stream.
Goal-like loop that uses ultrawork mode to decompose work into systematic, evidence-bound steps.
Execute a Prometheus work plan in Codex with Boulder state, evidence ledger updates, worktree discipline, parallel subagents, and Stop-hook continuation. Use after planning when the user says start work, execute plan, continue plan, resume plan, or asks to run a .omo/plans plan.
Rigorous visual QA for any UI you built or changed, across BOTH web/page UIs and TUI/terminal UIs. MUST USE after building or changing any UI to verify it visually before declaring it done. Captures objective reference evidence with a bundled diff script (image-diff for screenshots, tui-check for terminal captures), then runs two parallel read-only oracle passes (design-system and functional integrity; visual fidelity and CJK precision) and synthesizes one good/bad verdict. Triggers: visual QA, visual regression, screenshot diff, pixel diff, image comparison, UI looks wrong, design system check, is this really a design system or just an image, alpha channel breakage, responsive check, CJK text, Korean/Japanese/Chinese text clipping or semantic line breaks, baseline drop, glyph drop, TUI alignment, terminal UI, tmux capture, box-drawing border misalignment, wide-character column drift. Use it even when the user does not say visual QA but asks whether a page, component, or terminal layout looks right.
| name | publish |
| description | Publish oh-my-opencode to npm via GitHub Actions workflow. Argument: <patch|minor|major>. Triggers: publish, release, deploy, npm publish. |
You are the release manager for oh-my-opencode. Execute the FULL publish workflow from start to finish.
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 | /get-unpublished-changes and pre-publish review include layer-specific version impact. |
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.
Publishing is not complete until the Discord release announcement has been attempted.
You MUST receive a version bump type 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)If the user did not provide a bump type argument, STOP IMMEDIATELY and ask:
"To proceed with deployment, please specify a version bump type:
patch,minor, ormajor"
DO NOT PROCEED without explicit user confirmation of bump type.
Before doing ANYTHING else, create a detailed todo list using TodoWrite:
[
{ "id": "confirm-bump", "content": "Confirm version bump type with user (patch/minor/major)", "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": "wait-platform-workflow", "content": "Wait for publish-platform workflow completion", "status": "pending", "priority": "high" },
{ "id": "verify-platform-binaries", "content": "Verify all 7 platform binary packages published", "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.
If bump type provided as argument, confirm with user:
"Version bump type:
{bump}. Proceed? (y/n)"
Wait for user confirmation before proceeding.
Run: git status --porcelain
Check if there are unpushed commits:
git log origin/master..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.
Run the publish workflow:
gh workflow run publish -f bump={bump_type}
Wait 3 seconds, then get the run ID:
gh run list --workflow=publish --limit=1 --json databaseId,status --jq '.[0]'
Poll workflow status every 30 seconds until completion:
gh run view {run_id} --json status,conclusion --jq '{status: .status, conclusion: .conclusion}'
Status flow: queued → in_progress → completed
IMPORTANT: Use polling loop, NOT sleep commands.
If conclusion is failure, show error and stop:
gh run view {run_id} --log-failed
Two goals: confirm the release exists, then show the user what the workflow already generated.
# Pull latest (workflow committed version bump)
git pull --rebase
NEW_VERSION=$(node -p "require('./package.json').version")
# Verify release exists on GitHub
gh release view "v${NEW_VERSION}" --json tagName,url --jq '{tag: .tagName, url: .url}'
After verifying, generate a local preview of the auto-generated content:
bun run script/generate-changelog.ts
After running the preview, present the output to the user and say:
The following content is ALREADY included in the release automatically:
- Commit changelog (grouped by feat/fix/refactor)
- Contributor thank-you messages (for non-team contributors)
You do NOT need to write any of this. It's handled.
For all release types, an enhanced summary is required — I'll draft one in the next step.
Wait for the user to acknowledge before proceeding.
If the user already confirmed the publish workflow and did not explicitly ask to review the generated changelog before release-note editing, treat the publish confirmation as sufficient acknowledgement and continue. Do not end the assistant turn here.
| 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. |
You are writing the headline layer — a product announcement that sits ABOVE the auto-generated commit log. Think "release blog post", not "git log".
- NEVER duplicate commit messages. The auto-generated section already lists every commit. - NEVER write generic filler like "Various bug fixes and improvements" or "Several enhancements". - ALWAYS focus on USER IMPACT: what can users DO now that they couldn't before? - ALWAYS group by THEME or CAPABILITY, not by commit type (feat/fix/refactor). - ALWAYS use concrete language: "You can now do X" not "Added X feature". ## What's New - feat(auth): add JWT refresh token rotation - fix(auth): handle expired token edge case - refactor(auth): extract middleware ## 🔐 Smarter AuthenticationToken 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.
## Improvements - Various performance improvements - Bug fixes and stability enhancements ## ⚡ 3x Faster Rule ParsingRules 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.
/tmp/release-summary-v${NEW_VERSION}.md.# 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
After drafting, ask the user:
> "Here's the release summary I drafted. This will appear AT THE TOP of the release notes, above the auto-generated commit changelog and contributor thanks. Want me to adjust anything before applying?"
If the user already confirmed the publish workflow and did not explicitly request a release-note review hold, proceed to Step 7 after presenting the draft. Do not stop before Step 7.5, because the Discord announcement is mandatory.
This step is MANDATORY. The enhanced summary from Step 6 must always be applied.
The final release note structure:┌─────────────────────────────────────┐
│ 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 │
└─────────────────────────────────────┘
- Fetch the existing release body FIRST
- PREPEND your summary above it
- The existing auto-generated content must remain 100% INTACT
- NOT A SINGLE CHARACTER of existing content may be removed or modified
# 1. Fetch existing auto-generated body
EXISTING_BODY=$(gh release view "v${NEW_VERSION}" --json body --jq '.body')
# 2. Combine: enhanced summary on top, auto-generated below
{
cat /tmp/release-summary-v${NEW_VERSION}.md
echo ""
echo "---"
echo ""
echo "$EXISTING_BODY"
} > /tmp/final-release-v${NEW_VERSION}.md
# 3. Update the release (additive only)
gh release edit "v${NEW_VERSION}" --notes-file /tmp/final-release-v${NEW_VERSION}.md
# 4. Confirm
echo "✅ Release v${NEW_VERSION} updated with enhanced summary."
gh release view "v${NEW_VERSION}" --json url --jq '.url'
After the release notes are finalized, post them to the Discord channel. This step is mandatory for every publish run.
The workflow is not complete until this step has either: 1. Sent a Discord message successfully and recorded the message ID, or 2. Failed after `agent-discordbot auth status` plus one send retry, with the Jobdori bot-token failure reported to the user.Never skip this step because the release summary was awaiting approval. If the user already confirmed the publish, continue through Discord before stopping.
1. Use the Jobdori bot token through `agent-discordbot` for release announcements. This is the required release path; do not use the personal `agent-discord` token unless the bot path is unavailable and the user explicitly approves the fallback. Pin the bot id so release messages go out as the Jobdori bot even if the local `agent-discordbot` current bot changes. ```bash JOBDORI_BOT_ID=1486173823354146917 agent-discordbot auth status --bot "$JOBDORI_BOT_ID" ```JOBDORI_BOT_ID=1486173823354146917
agent-discordbot message list 1454708427392680067 --bot "$JOBDORI_BOT_ID" --limit 5
If agent-discordbot is unavailable or unauthorized, stop and report that the Jobdori 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:
@here
🎉 **oh-my-opencode v{VERSION} — {Short Tagline}**
**Feature 1** — one-line description.
**Feature 2** — one-line description.
**Feature 3** — one-line description.
Plus {summary of remaining changes}.
📦 Install / upgrade:
`bun i -g oh-my-opencode@{VERSION}` (or `npm`)
📝 Full release notes: {RELEASE_URL}
JOBDORI_BOT_ID=1486173823354146917
RELEASE_URL=$(gh release view "v${NEW_VERSION}" --json url --jq '.url')
agent-discordbot message send 1454708427392680067 "{your message following the style above}" --bot "$JOBDORI_BOT_ID"
If the message fails to send, warn the user and continue — do NOT block the publish workflow on Discord errors.
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.
The main publish workflow triggers a separate publish-platform workflow for platform-specific binaries.
gh run list --workflow=publish-platform --limit=1 --json databaseId,status,conclusion --jq '.[0]'
gh run view {platform_run_id} --json status,conclusion --jq '{status: .status, conclusion: .conclusion}'
IMPORTANT: Use polling loop, NOT sleep commands.
If conclusion is failure, show error logs:
gh run view {platform_run_id} --log-failed
After publish-platform workflow completes, verify all 7 platform packages are published:
PLATFORMS="darwin-arm64 darwin-x64 linux-x64 linux-arm64 linux-x64-musl linux-arm64-musl windows-x64"
for PLATFORM in $PLATFORMS; do
npm view "oh-my-opencode-${PLATFORM}" version
done
All 7 packages should show the same version as the main package (${NEW_VERSION}).
Expected packages:
| Package | Description |
|---|---|
oh-my-opencode-darwin-arm64 | macOS Apple Silicon |
oh-my-opencode-darwin-x64 | macOS Intel |
oh-my-opencode-linux-x64 | Linux x64 (glibc) |
oh-my-opencode-linux-arm64 | Linux ARM64 (glibc) |
oh-my-opencode-linux-x64-musl | Linux x64 (musl/Alpine) |
oh-my-opencode-linux-arm64-musl | Linux ARM64 (musl/Alpine) |
oh-my-opencode-windows-x64 | Windows x64 |
If any platform package version doesn't match, warn the user and suggest checking the publish-platform workflow logs.
Report success to user with:
gh auth loginRespond to user in English.