oh-my-opencode 4.19.2 → 4.19.4

package/.agents/command/get-unpublished-changes.md

@@ -22,6 +22,8 @@ Analyze every change against these exact layers:
 | `omo opencode` | Root `oh-my-opencode` / `oh-my-openagent`, `src/`, `.opencode/`, `.agents/`, CLI, config, hooks, tools, docs | What semver bump should the OpenCode/OpenAgent npm packages use? |
 | `omo codex` | `packages/omo-codex`, `lazycodex-ai`, Codex plugin metadata/hooks, bundled MCP runtimes, `code-yeongyu/lazycodex` marketplace payload | Does LazyCodex need the same bump, a Codex-only note, or a marketplace release? |
 
+Exclude commits and paths matching `senpi`, `omo-senpi`, `senpi-task`, `pi-goal`, or `pi-webfetch` from user-facing notes and version recommendations. Record them only in a separate internal-adapter exclusion ledger.
+
 ## Steps:
 1. Detect latest published versions for `oh-my-opencode`, `oh-my-openagent`, and `lazycodex-ai`.
 2. Run `git diff v{published-version}..HEAD` to see actual changes.

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.6 Sol), Librarian & Explore (GPT-5.4 Mini Fast), Frontend Engineer (Gemini), and more
+- 🤖 **Multi-Agent Orchestration**: Oracle (GPT-5.6 Sol), Librarian & Explore (GPT 5.6 Luna 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

@@ -3,7 +3,7 @@ description: Publish oh-my-opencode to npm via GitHub Actions workflow
 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
@@ -26,6 +26,32 @@ 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 a version bump type from the user.** Valid options:
@@ -52,8 +78,9 @@ The publish workflow must not be reported complete while any of `oh-my-opencode`
   { "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 minor/major, optional for patch — ask user)", "status": "pending", "priority": "high" },
-  { "id": "apply-summary", "content": "Prepend enhanced summary to release (if user opted in)", "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" },
@@ -163,10 +190,9 @@ After running the preview, present the output to the user and say:
 >
 > You do NOT need to write any of this. It's handled.
 >
-> **For a patch release**, this is usually sufficient on its own. However, if there are notable bug fixes or changes worth highlighting, an enhanced summary can be added.
-> **For a minor/major release**, an enhanced summary is **required** — I'll draft one in the next step.
+> **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.
+**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.
 </agent-instruction>
 
 ---
@@ -177,12 +203,18 @@ Wait for the user to acknowledge before proceeding.
 
 | Release Type | Action |
 |-------------|--------|
-| **patch** | ASK the user: "Would you like me to draft an enhanced summary highlighting the key bug fixes / changes? Or is the auto-generated changelog sufficient?" If user declines → skip to Step 8. If user accepts → draft a concise bug-fix / change summary below. |
+| **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. |
 
 </decision-gate>
 
+### 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".
@@ -193,6 +225,7 @@ You are writing the **headline layer** — a product announcement that sits ABOV
 - 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".
+- NEVER include internal adapter changes matching `senpi`, `omo-senpi`, `senpi-task`, `pi-goal`, or `pi-webfetch` in either release-note variant.
 </rules>
 
 <examples>
@@ -238,17 +271,17 @@ cat /tmp/release-summary-v${NEW_VERSION}.md
 ```
 
 <agent-instruction>
-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?"
+Present the draft to 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."
 
-Do NOT proceed to Step 7 without user confirmation.
+**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.
 </agent-instruction>
 
 ---
 
 ## STEP 7: APPLY ENHANCED SUMMARY TO RELEASE
 
-**Skip this step ONLY if the user opted out of the enhanced summary in Step 6** — proceed directly to Step 8.
+This step is MANDATORY. The enhanced summary from Step 6 must always be applied.
 
 <architecture>
 The final release note structure:
@@ -297,6 +330,64 @@ gh release view "v${NEW_VERSION}" --json url --jq '.url'
 
 ---
 
+## STEP 7.5: POST RELEASE NOTES TO DISCORD
+
+After the release notes are finalized, post them to the Discord channel. This step is mandatory for every publish run.
+
+<hard-gate>
+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.
+</hard-gate>
+
+<agent-discord-instruction>
+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"
+```
+
+2. **Read recent messages** in the channel to match the existing announcement style:
+```bash
+JOBDORI_BOT_ID=1486173823354146917
+agent-discordbot message list 1454708427392680067 --bot "$JOBDORI_BOT_ID" --limit 5
+```
+
+3. 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`.
+
+4. 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}
+```
+
+```bash
+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.
+</agent-discord-instruction>
+
+---
+
 ## STEP 8: VERIFY NPM PUBLICATION
 
 Poll npm registry until the new version appears:
@@ -343,20 +434,3 @@ Report success to user with:
 ## LANGUAGE
 
 Respond to user in English.
-
-</command-instruction>
-
-<current-context>
-<published-version>
-!`npm view oh-my-opencode version 2>/dev/null || echo "not published"`
-</published-version>
-<local-version>
-!`node -p "require('./package.json').version" 2>/dev/null || echo "unknown"`
-</local-version>
-<git-status>
-!`git status --porcelain`
-</git-status>
-<recent-commits>
-!`npm view oh-my-opencode version 2>/dev/null | xargs -I{} git log "v{}"..HEAD --oneline 2>/dev/null | head -15 || echo "no commits"`
-</recent-commits>
-</current-context>

package/.agents/skills/get-unpublished-changes/SKILL.md

@@ -22,6 +22,8 @@ Analyze every change against these exact layers:
 | `omo opencode` | Root `oh-my-opencode` / `oh-my-openagent`, `src/`, `.opencode/`, `.agents/`, CLI, config, hooks, tools, docs | What semver bump should the OpenCode/OpenAgent npm packages use? |
 | `omo codex` | `packages/omo-codex`, `lazycodex-ai`, Codex plugin metadata/hooks, bundled MCP runtimes, `code-yeongyu/lazycodex` marketplace payload | Does LazyCodex need the same bump, a Codex-only note, or a marketplace release? |
 
+Exclude commits and paths matching `senpi`, `omo-senpi`, `senpi-task`, `pi-goal`, or `pi-webfetch` from user-facing notes and version recommendations. Record them only in a separate internal-adapter exclusion ledger.
+
 ## Steps:
 1. Detect latest published versions for `oh-my-opencode`, `oh-my-openagent`, and `lazycodex-ai`.
 2. Run `git diff v{published-version}..HEAD` to see actual changes.

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

@@ -33,10 +33,10 @@ Required categories are `unspecified-low`, `unspecified-high`, `ultrabrain`, and
 | Category | Model | Native Mindset | Why This Adversarial Role Fits |
 |----------|-------|----------------|--------------------------------|
 | `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.6-terra xhigh | Autonomous, exploration-heavy, evidence-driven | Autonomous Researcher — natural exploration bias attacks unfounded claims |
+| `unspecified-high` | kimi-k3 max -> claude-opus-5 xhigh -> gpt-5.6-sol high | High-effort, broad-impact, coordination-aware | Integration Tester — max-tier broad-scope thinking exposes cross-module fragility |
+| `deep` | gpt-5.6-sol medium | 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 |
+| `artistry` | claude-fable-5 xhigh | 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.6 Sol), Librarian & Explore (GPT-5.4 Mini Fast), Frontend Engineer (Gemini), and more
+- 🤖 **Multi-Agent Orchestration**: Oracle (GPT-5.6 Sol), Librarian & Explore (GPT 5.6 Luna 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/publish/SKILL.md

@@ -35,6 +35,22 @@ Publishing is not complete until the Discord release announcement has been attem
 - 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 a version bump type from the user.** Valid options:
@@ -175,9 +191,7 @@ After running the preview, present the output to the user and say:
 >
 > **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.
+**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.
 </agent-instruction>
 
 ---
@@ -194,6 +208,12 @@ If the user already confirmed the publish workflow and did not explicitly ask to
 
 </decision-gate>
 
+### 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".
@@ -204,6 +224,7 @@ You are writing the **headline layer** — a product announcement that sits ABOV
 - 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".
+- NEVER include internal adapter changes matching `senpi`, `omo-senpi`, `senpi-task`, `pi-goal`, or `pi-webfetch` in either release-note variant.
 </rules>
 
 <examples>
@@ -249,10 +270,10 @@ cat /tmp/release-summary-v${NEW_VERSION}.md
 ```
 
 <agent-instruction>
-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?"
+Present the draft to 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."
 
-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.
+**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.
 </agent-instruction>
 
 ---

package/.opencode/command/get-unpublished-changes.md

@@ -22,6 +22,8 @@ Analyze every change against these exact layers:
 | `omo opencode` | Root `oh-my-opencode` / `oh-my-openagent`, `src/`, `.opencode/`, `.agents/`, CLI, config, hooks, tools, docs | What semver bump should the OpenCode/OpenAgent npm packages use? |
 | `omo codex` | `packages/omo-codex`, `lazycodex-ai`, Codex plugin metadata/hooks, bundled MCP runtimes, `code-yeongyu/lazycodex` marketplace payload | Does LazyCodex need the same bump, a Codex-only note, or a marketplace release? |
 
+Exclude commits and paths matching `senpi`, `omo-senpi`, `senpi-task`, `pi-goal`, or `pi-webfetch` from user-facing notes and version recommendations. Record them only in a separate internal-adapter exclusion ledger.
+
 ## Steps:
 1. Detect latest published versions for `oh-my-opencode`, `oh-my-openagent`, and `lazycodex-ai`.
 2. Run `git diff v{published-version}..HEAD` to see actual changes.

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.6 Sol), Librarian & Explore (GPT-5.4 Mini Fast), Frontend Engineer (Gemini), and more
+- 🤖 **Multi-Agent Orchestration**: Oracle (GPT-5.6 Sol), Librarian & Explore (GPT 5.6 Luna 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

@@ -3,7 +3,7 @@ description: Publish oh-my-opencode to npm via GitHub Actions workflow
 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
@@ -26,6 +26,32 @@ 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 a version bump type from the user.** Valid options:
@@ -52,8 +78,9 @@ The publish workflow must not be reported complete while any of `oh-my-opencode`
   { "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 minor/major, optional for patch — ask user)", "status": "pending", "priority": "high" },
-  { "id": "apply-summary", "content": "Prepend enhanced summary to release (if user opted in)", "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" },
@@ -163,10 +190,9 @@ After running the preview, present the output to the user and say:
 >
 > You do NOT need to write any of this. It's handled.
 >
-> **For a patch release**, this is usually sufficient on its own. However, if there are notable bug fixes or changes worth highlighting, an enhanced summary can be added.
-> **For a minor/major release**, an enhanced summary is **required** — I'll draft one in the next step.
+> **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.
+**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.
 </agent-instruction>
 
 ---
@@ -177,12 +203,18 @@ Wait for the user to acknowledge before proceeding.
 
 | Release Type | Action |
 |-------------|--------|
-| **patch** | ASK the user: "Would you like me to draft an enhanced summary highlighting the key bug fixes / changes? Or is the auto-generated changelog sufficient?" If user declines → skip to Step 8. If user accepts → draft a concise bug-fix / change summary below. |
+| **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. |
 
 </decision-gate>
 
+### 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".
@@ -193,6 +225,7 @@ You are writing the **headline layer** — a product announcement that sits ABOV
 - 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".
+- NEVER include internal adapter changes matching `senpi`, `omo-senpi`, `senpi-task`, `pi-goal`, or `pi-webfetch` in either release-note variant.
 </rules>
 
 <examples>
@@ -238,17 +271,17 @@ cat /tmp/release-summary-v${NEW_VERSION}.md
 ```
 
 <agent-instruction>
-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?"
+Present the draft to 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."
 
-Do NOT proceed to Step 7 without user confirmation.
+**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.
 </agent-instruction>
 
 ---
 
 ## STEP 7: APPLY ENHANCED SUMMARY TO RELEASE
 
-**Skip this step ONLY if the user opted out of the enhanced summary in Step 6** — proceed directly to Step 8.
+This step is MANDATORY. The enhanced summary from Step 6 must always be applied.
 
 <architecture>
 The final release note structure:
@@ -297,6 +330,64 @@ gh release view "v${NEW_VERSION}" --json url --jq '.url'
 
 ---
 
+## STEP 7.5: POST RELEASE NOTES TO DISCORD
+
+After the release notes are finalized, post them to the Discord channel. This step is mandatory for every publish run.
+
+<hard-gate>
+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.
+</hard-gate>
+
+<agent-discord-instruction>
+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"
+```
+
+2. **Read recent messages** in the channel to match the existing announcement style:
+```bash
+JOBDORI_BOT_ID=1486173823354146917
+agent-discordbot message list 1454708427392680067 --bot "$JOBDORI_BOT_ID" --limit 5
+```
+
+3. 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`.
+
+4. 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}
+```
+
+```bash
+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.
+</agent-discord-instruction>
+
+---
+
 ## STEP 8: VERIFY NPM PUBLICATION
 
 Poll npm registry until the new version appears:
@@ -343,20 +434,3 @@ Report success to user with:
 ## LANGUAGE
 
 Respond to user in English.
-
-</command-instruction>
-
-<current-context>
-<published-version>
-!`npm view oh-my-opencode version 2>/dev/null || echo "not published"`
-</published-version>
-<local-version>
-!`node -p "require('./package.json').version" 2>/dev/null || echo "unknown"`
-</local-version>
-<git-status>
-!`git status --porcelain`
-</git-status>
-<recent-commits>
-!`npm view oh-my-opencode version 2>/dev/null | xargs -I{} git log "v{}"..HEAD --oneline 2>/dev/null | head -15 || echo "no commits"`
-</recent-commits>
-</current-context>

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

@@ -33,10 +33,10 @@ Required categories are `unspecified-low`, `unspecified-high`, `ultrabrain`, and
 | Category | Model | Native Mindset | Why This Adversarial Role Fits |
 |----------|-------|----------------|--------------------------------|
 | `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.6-terra xhigh | Autonomous, exploration-heavy, evidence-driven | Autonomous Researcher — natural exploration bias attacks unfounded claims |
+| `unspecified-high` | kimi-k3 max -> claude-opus-5 xhigh -> gpt-5.6-sol high | High-effort, broad-impact, coordination-aware | Integration Tester — max-tier broad-scope thinking exposes cross-module fragility |
+| `deep` | gpt-5.6-sol medium | 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 |
+| `artistry` | claude-fable-5 xhigh | Unconventional, pattern-breaking, lateral | Creative Challenger — pattern-breaking bias attacks orthodox thinking |
 
 ### MEMBER 1: `skeptic` (category: `unspecified-low`)
 

package/THIRD-PARTY-NOTICES.md

@@ -24,43 +24,43 @@ Generator/checker note: update this file with the audited component list, then r
 - Upstream URL: https://github.com/code-yeongyu/go-claude-code-comment-checker
 - Where-bundled: root production dependency and vendored checker binary payload under `vendor/<platform>/`.
 
-### @colbymchenry/codegraph@1.0.1
+### @colbymchenry/codegraph@1.5.0
 - License: MIT, from npm package metadata. The inspected tarball did not include a separate LICENSE file.
 - Copyright: CodeGraph contributors.
 - Upstream URL: https://www.npmjs.com/package/@colbymchenry/codegraph
 - Where-bundled: pinned CodeGraph provisioning payload for the CodeGraph OMO integration.
 
-### @colbymchenry/codegraph-darwin-arm64@1.0.1
+### @colbymchenry/codegraph-darwin-arm64@1.5.0
 - License: MIT, from npm package metadata. The inspected tarball did not include a separate LICENSE file.
 - Copyright: CodeGraph contributors.
 - Upstream URL: https://www.npmjs.com/package/@colbymchenry/codegraph-darwin-arm64
 - Where-bundled: optional CodeGraph platform bundle for darwin arm64, including CodeGraph runtime files, Node.js runtime binary, and tree-sitter WASM assets.
 
-### @colbymchenry/codegraph-darwin-x64@1.0.1
+### @colbymchenry/codegraph-darwin-x64@1.5.0
 - License: MIT, from npm package metadata. The inspected tarball did not include a separate LICENSE file.
 - Copyright: CodeGraph contributors.
 - Upstream URL: https://www.npmjs.com/package/@colbymchenry/codegraph-darwin-x64
 - Where-bundled: optional CodeGraph platform bundle for darwin x64, including CodeGraph runtime files, Node.js runtime binary, and tree-sitter WASM assets.
 
-### @colbymchenry/codegraph-linux-arm64@1.0.1
+### @colbymchenry/codegraph-linux-arm64@1.5.0
 - License: MIT, from npm package metadata. The inspected tarball did not include a separate LICENSE file.
 - Copyright: CodeGraph contributors.
 - Upstream URL: https://www.npmjs.com/package/@colbymchenry/codegraph-linux-arm64
 - Where-bundled: optional CodeGraph platform bundle for linux arm64, including CodeGraph runtime files, Node.js runtime binary, and tree-sitter WASM assets.
 
-### @colbymchenry/codegraph-linux-x64@1.0.1
+### @colbymchenry/codegraph-linux-x64@1.5.0
 - License: MIT, from npm package metadata. The inspected tarball did not include a separate LICENSE file.
 - Copyright: CodeGraph contributors.
 - Upstream URL: https://www.npmjs.com/package/@colbymchenry/codegraph-linux-x64
 - Where-bundled: optional CodeGraph platform bundle for linux x64, including CodeGraph runtime files, Node.js runtime binary, and tree-sitter WASM assets.
 
-### @colbymchenry/codegraph-win32-arm64@1.0.1
+### @colbymchenry/codegraph-win32-arm64@1.5.0
 - License: MIT, from npm package metadata. The inspected tarball did not include a separate LICENSE file.
 - Copyright: CodeGraph contributors.
 - Upstream URL: https://www.npmjs.com/package/@colbymchenry/codegraph-win32-arm64
 - Where-bundled: optional CodeGraph platform bundle for win32 arm64, including CodeGraph runtime files, Node.js runtime binary, and tree-sitter WASM assets.
 
-### @colbymchenry/codegraph-win32-x64@1.0.1
+### @colbymchenry/codegraph-win32-x64@1.5.0
 - License: MIT, from npm package metadata. The inspected tarball did not include a separate LICENSE file.
 - Copyright: CodeGraph contributors.
 - Upstream URL: https://www.npmjs.com/package/@colbymchenry/codegraph-win32-x64