oh-my-opencode 4.16.3 → 4.17.1

package/.agents/command/omomomo.md

@@ -17,7 +17,7 @@ Print the following message to the user EXACTLY as written (in a friendly, celeb
 
 **Oh My OpenCode** is a powerful OpenCode plugin that transforms your AI agent into a full development team:
 
-- 🤖 **Multi-Agent Orchestration**: Oracle (GPT-5.5), Librarian (Claude), Explore (Grok), Frontend Engineer (Gemini), and more
+- 🤖 **Multi-Agent Orchestration**: Oracle (GPT-5.5), Librarian & Explore (GPT-5.4 Mini Fast), Frontend Engineer (Gemini), and more
 - 🔧 **LSP Tools**: Full IDE capabilities for your agents - hover, goto definition, find references, rename, code actions
 - 🔍 **AST-Grep**: Structural code search and replace across 25 languages
 - 📚 **Built-in MCPs**: Context7 for docs, Exa for web search, grep.app for GitHub code search

package/.agents/command/publish.md

@@ -6,13 +6,21 @@ argument-hint: <patch|minor|major>
 <command-instruction>
 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 | `/get-unpublished-changes` and pre-publish review include layer-specific version impact. |
+| `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. |
 
@@ -48,8 +56,7 @@ The publish workflow must not be reported complete while any of `oh-my-opencode`
   { "id": "apply-summary", "content": "Prepend enhanced summary to release (if user opted in)", "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": "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" }
 ]
 ```
@@ -60,10 +67,7 @@ The publish workflow must not be reported complete while any of `oh-my-opencode`
 
 ## STEP 1: CONFIRM BUMP TYPE
 
-If bump type provided as argument, confirm with user:
-> "Version bump type: `{bump}`. Proceed? (y/n)"
-
-Wait for user confirmation before proceeding.
+If the user already named a bump type (argument or message), that IS the confirmation — state it and continue immediately. Only ask and wait when no bump type was given.
 
 ---
 
@@ -80,7 +84,7 @@ Run: `git status --porcelain`
 
 Check if there are unpushed commits:
 ```bash
-git log origin/master..HEAD --oneline
+git log @{u}..HEAD --oneline
 ```
 
 **If there are unpushed commits, you MUST sync before triggering workflow:**
@@ -108,14 +112,21 @@ gh run list --workflow=publish --limit=1 --json databaseId,status --jq '.[0]'
 
 ## STEP 4: WAIT FOR WORKFLOW COMPLETION
 
-Poll workflow status every 30 seconds until 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 | 3–4 min |
+| `publish-main` → `release` | Publishes `oh-my-opencode` / `oh-my-openagent` / `lazycodex-ai`, creates the GitHub release, syncs `code-yeongyu/lazycodex` | 4–6 min |
+
+Poll job-level status every 30 seconds and report stage transitions to the user:
 ```bash
-gh run view {run_id} --json status,conclusion --jq '{status: .status, conclusion: .conclusion}'
+gh run view {run_id} --json status,conclusion,jobs --jq '{status, conclusion, stage: ([.jobs[] | select(.status=="in_progress") | .name] | join(", "))}'
 ```
 
-Status flow: `queued` → `in_progress` → `completed`
-
-**IMPORTANT: Use polling loop, NOT sleep commands.**
+**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.
 
 If conclusion is `failure`, show error and stop:
 ```bash
@@ -297,54 +308,17 @@ Compare with expected version. If not matching after 2 minutes, warn user about
 
 ---
 
-## STEP 8.5: WAIT FOR PLATFORM WORKFLOW COMPLETION
-
-The main publish workflow triggers a separate `publish-platform` workflow for platform-specific binaries.
-
-1. Find the publish-platform workflow run triggered by the main workflow:
-```bash
-gh run list --workflow=publish-platform --limit=1 --json databaseId,status,conclusion --jq '.[0]'
-```
-
-2. Poll workflow status every 30 seconds until completion:
-```bash
-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:
-```bash
-gh run view {platform_run_id} --log-failed
-```
-
----
-
-## STEP 8.6: VERIFY PLATFORM BINARY PACKAGES
+## STEP 8.5: SPOT-CHECK PLATFORM BINARY PACKAGES
 
-After publish-platform workflow completes, verify all 7 platform packages are published:
+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:
 
 ```bash
-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
+for PKG in oh-my-opencode-darwin-arm64 oh-my-openagent-linux-x64 oh-my-opencode-windows-x64; do
+  npm view "$PKG" 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.
+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.
 
 ---
 
@@ -354,7 +328,7 @@ Report success to user with:
 - New version number
 - GitHub release URL: https://github.com/code-yeongyu/oh-my-opencode/releases/tag/v{version}
 - npm package URL: https://www.npmjs.com/package/oh-my-opencode
-- Platform packages status: List all 7 platform packages with their versions
+- Platform packages status: spot-checked platform package versions
 
 ---
 
@@ -364,8 +338,7 @@ Report success to user with:
 - **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 workflow fails**: Show logs from publish-platform workflow, check which platform failed
-- **Platform package missing**: Some platforms may fail due to cross-compilation issues, suggest re-running publish-platform workflow manually
+- **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
 
 ## LANGUAGE
 

package/.agents/skills/hyperplan/SKILL.md

@@ -32,10 +32,10 @@ Required categories are `unspecified-low`, `unspecified-high`, `ultrabrain`, and
 
 | Category | Model | Native Mindset | Why This Adversarial Role Fits |
 |----------|-------|----------------|--------------------------------|
-| `unspecified-low` | claude-sonnet-4-6 | Mid-tier, simplicity-leaning, structure-demanding | Pragmatist Skeptic — model bias toward simplicity makes it the natural enemy of over-engineering |
+| `unspecified-low` | gpt-5.6-luna xhigh | Mid-tier, simplicity-leaning, structure-demanding | Pragmatist Skeptic — model bias toward simplicity makes it the natural enemy of over-engineering |
 | `unspecified-high` | claude-opus-4-7 max | High-effort, broad-impact, coordination-aware | Integration Tester — max-tier broad-scope thinking exposes cross-module fragility |
-| `deep` | gpt-5.5 medium | Autonomous, exploration-heavy, evidence-driven | Autonomous Researcher — natural exploration bias attacks unfounded claims |
-| `ultrabrain` | gpt-5.5 xhigh | Hard-logic, simplicity-biased, strategic advisor | Architect Strategist — xhigh reasoning sees structural flaws others miss |
+| `deep` | gpt-5.6-terra xhigh | Autonomous, exploration-heavy, evidence-driven | Autonomous Researcher — natural exploration bias attacks unfounded claims |
+| `ultrabrain` | gpt-5.6-sol xhigh | Hard-logic, simplicity-biased, strategic advisor | Architect Strategist — xhigh reasoning sees structural flaws others miss |
 | `artistry` | gemini-3.1-pro high | Unconventional, pattern-breaking, lateral | Creative Challenger — pattern-breaking bias attacks orthodox thinking |
 
 ### MEMBER 1: `skeptic` (category: `unspecified-low`)

package/.agents/skills/omomomo/SKILL.md

@@ -17,7 +17,7 @@ Print the following message to the user EXACTLY as written (in a friendly, celeb
 
 **Oh My OpenCode** is a powerful OpenCode plugin that transforms your AI agent into a full development team:
 
-- 🤖 **Multi-Agent Orchestration**: Oracle (GPT-5.5), Librarian (Claude), Explore (Grok), Frontend Engineer (Gemini), and more
+- 🤖 **Multi-Agent Orchestration**: Oracle (GPT-5.5), Librarian & Explore (GPT-5.4 Mini Fast), Frontend Engineer (Gemini), and more
 - 🔧 **LSP Tools**: Full IDE capabilities for your agents - hover, goto definition, find references, rename, code actions
 - 🔍 **AST-Grep**: Structural code search and replace across 25 languages
 - 📚 **Built-in MCPs**: Context7 for docs, Exa for web search, grep.app for GitHub code search

package/.agents/skills/pre-publish-review/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: pre-publish-review
-description: "Nuclear-grade 16-agent pre-publish release gate. Runs /get-unpublished-changes to detect all changes since last npm release, spawns up to 10 ultrabrain agents for deep per-change analysis, invokes /review-work (5 agents) for holistic review, and 1 oracle for overall release synthesis. Use before EVERY npm publish. Triggers: 'pre-publish review', 'review before publish', 'release review', 'pre-release review', 'ready to publish?', 'can I publish?', 'pre-publish', 'safe to publish', 'publishing review', 'pre-publish check'."
+description: "Nuclear-grade 16-agent pre-publish release gate. Runs /get-unpublished-changes to detect all changes since last npm release, spawns up to 10 ultrabrain agents for deep per-change analysis, invokes /review-work (5 agents) for holistic review, and 1 oracle for overall release synthesis. Runs ONLY when the user explicitly asks for a pre-publish review — a plain publish/release request MUST NOT trigger this; /publish ships directly. Triggers: 'pre-publish review', 'review before publish', 'release review', 'pre-release review', 'ready to publish?', 'can I publish?', 'pre-publish', 'safe to publish', 'publishing review', 'pre-publish check'."
 ---
 
 # Pre-Publish Review — 16-Agent Release Gate

package/.agents/skills/publish/SKILL.md

@@ -1,17 +1,25 @@
 ---
 name: publish
-description: "Publish oh-my-opencode to npm via GitHub Actions workflow. Argument: <patch|minor|major>. Triggers: publish, release, deploy, npm 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>. 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 | `/get-unpublished-changes` and pre-publish review include layer-specific version impact. |
+| `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. |
 
@@ -58,8 +66,7 @@ Publishing is not complete until the Discord release announcement has been attem
   { "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": "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" }
 ]
 ```
@@ -70,10 +77,7 @@ Publishing is not complete until the Discord release announcement has been attem
 
 ## STEP 1: CONFIRM BUMP TYPE
 
-If bump type provided as argument, confirm with user:
-> "Version bump type: `{bump}`. Proceed? (y/n)"
-
-Wait for user confirmation before proceeding.
+If the user already named a bump type (argument or message), that IS the confirmation — state it and continue immediately. Only ask and wait when no bump type was given.
 
 ---
 
@@ -90,7 +94,7 @@ Run: `git status --porcelain`
 
 Check if there are unpushed commits:
 ```bash
-git log origin/master..HEAD --oneline
+git log @{u}..HEAD --oneline
 ```
 
 **If there are unpushed commits, you MUST sync before triggering workflow:**
@@ -118,14 +122,21 @@ gh run list --workflow=publish --limit=1 --json databaseId,status --jq '.[0]'
 
 ## STEP 4: WAIT FOR WORKFLOW COMPLETION
 
-Poll workflow status every 30 seconds until 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 | 3–4 min |
+| `publish-main` → `release` | Publishes `oh-my-opencode` / `oh-my-openagent` / `lazycodex-ai`, creates the GitHub release, syncs `code-yeongyu/lazycodex` | 4–6 min |
+
+Poll job-level status every 30 seconds and report stage transitions to the user:
 ```bash
-gh run view {run_id} --json status,conclusion --jq '{status: .status, conclusion: .conclusion}'
+gh run view {run_id} --json status,conclusion,jobs --jq '{status, conclusion, stage: ([.jobs[] | select(.status=="in_progress") | .name] | join(", "))}'
 ```
 
-Status flow: `queued` → `in_progress` → `completed`
-
-**IMPORTANT: Use polling loop, NOT sleep commands.**
+**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.
 
 If conclusion is `failure`, show error and stop:
 ```bash
@@ -366,54 +377,17 @@ Compare with expected version. If not matching after 2 minutes, warn user about
 
 ---
 
-## STEP 8.5: WAIT FOR PLATFORM WORKFLOW COMPLETION
-
-The main publish workflow triggers a separate `publish-platform` workflow for platform-specific binaries.
-
-1. Find the publish-platform workflow run triggered by the main workflow:
-```bash
-gh run list --workflow=publish-platform --limit=1 --json databaseId,status,conclusion --jq '.[0]'
-```
-
-2. Poll workflow status every 30 seconds until completion:
-```bash
-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:
-```bash
-gh run view {platform_run_id} --log-failed
-```
-
----
-
-## STEP 8.6: VERIFY PLATFORM BINARY PACKAGES
+## STEP 8.5: SPOT-CHECK PLATFORM BINARY PACKAGES
 
-After publish-platform workflow completes, verify all 7 platform packages are published:
+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:
 
 ```bash
-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
+for PKG in oh-my-opencode-darwin-arm64 oh-my-openagent-linux-x64 oh-my-opencode-windows-x64; do
+  npm view "$PKG" 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.
+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.
 
 ---
 
@@ -423,7 +397,7 @@ Report success to user with:
 - New version number
 - GitHub release URL: https://github.com/code-yeongyu/oh-my-opencode/releases/tag/v{version}
 - npm package URL: https://www.npmjs.com/package/oh-my-opencode
-- Platform packages status: List all 7 platform packages with their versions
+- Platform packages status: spot-checked platform package versions
 
 ---
 
@@ -433,8 +407,7 @@ Report success to user with:
 - **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 workflow fails**: Show logs from publish-platform workflow, check which platform failed
-- **Platform package missing**: Some platforms may fail due to cross-compilation issues, suggest re-running publish-platform workflow manually
+- **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
 
 ## LANGUAGE
 

package/.opencode/command/omomomo.md

@@ -17,7 +17,7 @@ Print the following message to the user EXACTLY as written (in a friendly, celeb
 
 **Oh My OpenCode** is a powerful OpenCode plugin that transforms your AI agent into a full development team:
 
-- 🤖 **Multi-Agent Orchestration**: Oracle (GPT-5.5), Librarian (Claude), Explore (Grok), Frontend Engineer (Gemini), and more
+- 🤖 **Multi-Agent Orchestration**: Oracle (GPT-5.5), Librarian & Explore (GPT-5.4 Mini Fast), Frontend Engineer (Gemini), and more
 - 🔧 **LSP Tools**: Full IDE capabilities for your agents - hover, goto definition, find references, rename, code actions
 - 🔍 **AST-Grep**: Structural code search and replace across 25 languages
 - 📚 **Built-in MCPs**: Context7 for docs, Exa for web search, grep.app for GitHub code search

package/.opencode/command/publish.md

@@ -6,13 +6,21 @@ argument-hint: <patch|minor|major>
 <command-instruction>
 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 | `/get-unpublished-changes` and pre-publish review include layer-specific version impact. |
+| `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. |
 
@@ -48,8 +56,7 @@ The publish workflow must not be reported complete while any of `oh-my-opencode`
   { "id": "apply-summary", "content": "Prepend enhanced summary to release (if user opted in)", "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": "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" }
 ]
 ```
@@ -60,10 +67,7 @@ The publish workflow must not be reported complete while any of `oh-my-opencode`
 
 ## STEP 1: CONFIRM BUMP TYPE
 
-If bump type provided as argument, confirm with user:
-> "Version bump type: `{bump}`. Proceed? (y/n)"
-
-Wait for user confirmation before proceeding.
+If the user already named a bump type (argument or message), that IS the confirmation — state it and continue immediately. Only ask and wait when no bump type was given.
 
 ---
 
@@ -80,7 +84,7 @@ Run: `git status --porcelain`
 
 Check if there are unpushed commits:
 ```bash
-git log origin/master..HEAD --oneline
+git log @{u}..HEAD --oneline
 ```
 
 **If there are unpushed commits, you MUST sync before triggering workflow:**
@@ -108,14 +112,21 @@ gh run list --workflow=publish --limit=1 --json databaseId,status --jq '.[0]'
 
 ## STEP 4: WAIT FOR WORKFLOW COMPLETION
 
-Poll workflow status every 30 seconds until 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 | 3–4 min |
+| `publish-main` → `release` | Publishes `oh-my-opencode` / `oh-my-openagent` / `lazycodex-ai`, creates the GitHub release, syncs `code-yeongyu/lazycodex` | 4–6 min |
+
+Poll job-level status every 30 seconds and report stage transitions to the user:
 ```bash
-gh run view {run_id} --json status,conclusion --jq '{status: .status, conclusion: .conclusion}'
+gh run view {run_id} --json status,conclusion,jobs --jq '{status, conclusion, stage: ([.jobs[] | select(.status=="in_progress") | .name] | join(", "))}'
 ```
 
-Status flow: `queued` → `in_progress` → `completed`
-
-**IMPORTANT: Use polling loop, NOT sleep commands.**
+**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.
 
 If conclusion is `failure`, show error and stop:
 ```bash
@@ -297,54 +308,17 @@ Compare with expected version. If not matching after 2 minutes, warn user about
 
 ---
 
-## STEP 8.5: WAIT FOR PLATFORM WORKFLOW COMPLETION
-
-The main publish workflow triggers a separate `publish-platform` workflow for platform-specific binaries.
-
-1. Find the publish-platform workflow run triggered by the main workflow:
-```bash
-gh run list --workflow=publish-platform --limit=1 --json databaseId,status,conclusion --jq '.[0]'
-```
-
-2. Poll workflow status every 30 seconds until completion:
-```bash
-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:
-```bash
-gh run view {platform_run_id} --log-failed
-```
-
----
-
-## STEP 8.6: VERIFY PLATFORM BINARY PACKAGES
+## STEP 8.5: SPOT-CHECK PLATFORM BINARY PACKAGES
 
-After publish-platform workflow completes, verify all 7 platform packages are published:
+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:
 
 ```bash
-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
+for PKG in oh-my-opencode-darwin-arm64 oh-my-openagent-linux-x64 oh-my-opencode-windows-x64; do
+  npm view "$PKG" 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.
+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.
 
 ---
 
@@ -354,7 +328,7 @@ Report success to user with:
 - New version number
 - GitHub release URL: https://github.com/code-yeongyu/oh-my-opencode/releases/tag/v{version}
 - npm package URL: https://www.npmjs.com/package/oh-my-opencode
-- Platform packages status: List all 7 platform packages with their versions
+- Platform packages status: spot-checked platform package versions
 
 ---
 
@@ -364,8 +338,7 @@ Report success to user with:
 - **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 workflow fails**: Show logs from publish-platform workflow, check which platform failed
-- **Platform package missing**: Some platforms may fail due to cross-compilation issues, suggest re-running publish-platform workflow manually
+- **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
 
 ## LANGUAGE
 

package/.opencode/skills/hyperplan/SKILL.md

@@ -32,10 +32,10 @@ Required categories are `unspecified-low`, `unspecified-high`, `ultrabrain`, and
 
 | Category | Model | Native Mindset | Why This Adversarial Role Fits |
 |----------|-------|----------------|--------------------------------|
-| `unspecified-low` | claude-sonnet-4-6 | Mid-tier, simplicity-leaning, structure-demanding | Pragmatist Skeptic — model bias toward simplicity makes it the natural enemy of over-engineering |
+| `unspecified-low` | gpt-5.6-luna xhigh | Mid-tier, simplicity-leaning, structure-demanding | Pragmatist Skeptic — model bias toward simplicity makes it the natural enemy of over-engineering |
 | `unspecified-high` | claude-opus-4-7 max | High-effort, broad-impact, coordination-aware | Integration Tester — max-tier broad-scope thinking exposes cross-module fragility |
-| `deep` | gpt-5.5 medium | Autonomous, exploration-heavy, evidence-driven | Autonomous Researcher — natural exploration bias attacks unfounded claims |
-| `ultrabrain` | gpt-5.5 xhigh | Hard-logic, simplicity-biased, strategic advisor | Architect Strategist — xhigh reasoning sees structural flaws others miss |
+| `deep` | gpt-5.6-terra xhigh | Autonomous, exploration-heavy, evidence-driven | Autonomous Researcher — natural exploration bias attacks unfounded claims |
+| `ultrabrain` | gpt-5.6-sol xhigh | Hard-logic, simplicity-biased, strategic advisor | Architect Strategist — xhigh reasoning sees structural flaws others miss |
 | `artistry` | gemini-3.1-pro high | Unconventional, pattern-breaking, lateral | Creative Challenger — pattern-breaking bias attacks orthodox thinking |
 
 ### MEMBER 1: `skeptic` (category: `unspecified-low`)

package/.opencode/skills/pre-publish-review/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: pre-publish-review
-description: "Nuclear-grade 16-agent pre-publish release gate. Runs /get-unpublished-changes to detect all changes since last npm release, spawns up to 10 ultrabrain agents for deep per-change analysis, invokes /review-work (5 agents) for holistic review, and 1 oracle for overall release synthesis. Use before EVERY npm publish. Triggers: 'pre-publish review', 'review before publish', 'release review', 'pre-release review', 'ready to publish?', 'can I publish?', 'pre-publish', 'safe to publish', 'publishing review', 'pre-publish check'."
+description: "Nuclear-grade 16-agent pre-publish release gate. Runs /get-unpublished-changes to detect all changes since last npm release, spawns up to 10 ultrabrain agents for deep per-change analysis, invokes /review-work (5 agents) for holistic review, and 1 oracle for overall release synthesis. Runs ONLY when the user explicitly asks for a pre-publish review — a plain publish/release request MUST NOT trigger this; /publish ships directly. Triggers: 'pre-publish review', 'review before publish', 'release review', 'pre-release review', 'ready to publish?', 'can I publish?', 'pre-publish', 'safe to publish', 'publishing review', 'pre-publish check'."
 ---
 
 # Pre-Publish Review — 16-Agent Release Gate
@@ -89,6 +89,7 @@ For each change group, spawn one ultrabrain agent. Each gets only its portion of
 ```
 task(
   category="ultrabrain",
+  model="gpt-5.6-sol",
   run_in_background=true,
   load_skills=[],
   description="Deep analysis: {GROUP_NAME}",
@@ -165,6 +166,7 @@ Spawn a sub-agent that loads the `/review-work` skill. The review-work skill int
 ```
 task(
   category="unspecified-high",
+  model="gpt-5.6-sol",
   run_in_background=true,
   load_skills=["review-work"],
   description="Run /review-work on all unpublished changes",
@@ -195,6 +197,7 @@ The oracle gets the full picture — all commits, full diff stat, and changed fi
 ```
 task(
   subagent_type="oracle",
+  model="gpt-5.6-sol",
   run_in_background=true,
   load_skills=[],
   description="Oracle: overall release synthesis and version bump recommendation",

package/README.ja.md

@@ -193,11 +193,11 @@ Read this and tell me why it's not just another boilerplate: https://raw.githubu
 <td align="center"><img src=".github/assets/hephaestus.png" height="300" /></td>
 </tr></table>
 
-**Sisyphus** (`claude-opus-4-7` / **`kimi-k2.6`** / **`glm-5.1`**) はあなたのメインオーケストレーターです。計画を立て、専門家に委任し、攻撃的な並列実行でタスクを完了まで推進します。途中で投げ出すことはありません。
+**Sisyphus** (`claude-opus-4-7` / **`kimi-k2.6`** / **`glm-5`**) はあなたのメインオーケストレーターです。計画を立て、専門家に委任し、攻撃的な並列実行でタスクを完了まで推進します。途中で投げ出すことはありません。
 
-**Hephaestus** (`gpt-5.5`) はあなたの自律的なディープワーカーです。レシピではなく、目標を与えてください。手取り足取り教えなくても、コードベースを探索し、パターンを調査し、エンドツーエンドで実行します。*正当なる職人 (The Legitimate Craftsman).*
+**Hephaestus** (OpenAI または Vercel では `gpt-5.6-sol`、その次に `gpt-5.5`) はあなたの自律的なディープワーカーです。レシピではなく、目標を与えてください。手取り足取り教えなくても、コードベースを探索し、パターンを調査し、エンドツーエンドで実行します。*正当なる職人 (The Legitimate Craftsman).*
 
-**Prometheus** (`claude-opus-4-7` / **`kimi-k2.6`** / **`glm-5.1`**) はあなたの戦略プランナーです。インタビューモードで質問を投げ、スコープを特定し、コードに一行触れる前に詳細な計画を構築します。
+**Prometheus** (`claude-opus-4-7` / **`gpt-5.5`** / **`glm-5.2`**) はあなたの戦略プランナーです。インタビューモードで質問を投げ、スコープを特定し、コードに一行触れる前に詳細な計画を構築します。
 
 すべてのエージェントは、それぞれのモデルの強みに合わせてチューニングされています。手動でモデルを切り替える必要はありません。[詳しくはこちら →](docs/guide/overview.md)
 
@@ -240,7 +240,7 @@ Sisyphus がサブエージェントにタスクを委任する際、モデル
 | `quick`              | 単一ファイルの変更、タイポの修正     |
 | `ultrabrain`         | ハードロジック、アーキテクチャの決定 |
 
-エージェントは作業の種類を伝えるだけで、ハーネスが適切なモデルを選びます。`ultrabrain` はデフォルトで GPT-5.5 xhigh にルーティングされるようになりました。あなたが触るものは何もありません。
+エージェントは作業の種類を伝えるだけで、ハーネスが適切なモデルを選びます。`ultrabrain` は OpenAI または Vercel で利用可能な場合は GPT-5.6 Sol xhigh に、その次に GPT-5.5 xhigh にルーティングされます。あなたが触るものは何もありません。
 
 ### Claude Code 互換性