publish

あなたは oh-my-opencode のリリースマネージャーです。公開ワークフローを最初から最後まで完全に実行してください。

重要：公開はリリース専用です — 直ちにワークフローを開始してください

origin/dev ではすでに必須チェックが完了しています。すべての PR とプッシュで CI（3 つの OS でのテスト／型チェック／codex 互換性チェック）が実行されており、公開ワークフローでも公開前に同じ必須チェックが再実行されます。

• **公開の依頼では、/pre-publish-review、/review-work、またはコードの再レビューを絶対に実行しないでください。**これらはユーザーが明示的にレビューを依頼した場合にのみ実行します。
• **公開中にコードを「修正」したり、PR を開いたり、修正と再監査を繰り返したりしないでください。**ワークフローが失敗した場合や何か問題があるように見える場合は、報告して停止してください。公開はコードベースの修復を行う場ではありません。
• バンプ種別を指定した公開依頼は、数分でステップ 0 からステップ 3（トリガー）まで進みます。人手が必要な作業は、CI の実行中にリリースノートを作成することだけです。

重要：完全なワークフローには 3 つのリリース対象すべてが含まれます

すべてのリリース対象が検証されるまで、公開は完了していません。

リリースレイヤー	対象	必要な証拠
omo pure components	公開パッケージのペイロードに含まれるコア／MCP／共有スキルの変更	リリースノートで、レイヤー固有のバージョンへの影響を明記します（ワークフローの変更履歴から取得するか、ユーザーが依頼した場合は /get-unpublished-changes を使用します）。
omo opencode	oh-my-opencode と oh-my-openagent の npm パッケージ、およびプラットフォームパッケージ	選択したバンプに対応する npm バージョンと GitHub リリースが存在すること。
omo codex	lazycodex-ai、Codex プラグインのメタデータ、code-yeongyu/lazycodex マーケットプレイスのリリース	Codex プラグインのメタデータにリリースバージョンが設定され、lazycodex-ai が公開されていること。また、マーケットプレイスのペイロードに変更があった場合は、LazyCodex リポジトリのリリースが作成されていること。

oh-my-opencode、oh-my-openagent、lazycodex-ai、code-yeongyu/lazycodex のいずれかについて、検証が未解決のまま公開ワークフローを完了として報告してはいけません。

重要：完全なワークフローには Discord も含まれます

Discord でのリリース告知を試みるまで、公開は完了していません。

• GitHub リリースを作成しただけで終了しないでください。
• リリースノートの作成または適用だけで終了しないでください。
• ユーザーがすでに公開を承認している場合、再度の確認を待たないでください。
• リリースノートが確定したら、直ちにステップ 7.5 を実行して Discord に投稿してください。
• 認証と再試行の後も Discord への投稿に失敗した場合は、失敗を明確に報告し、残りの検証手順を続けてください。Discord の手順を省略した場合、ワークフローの失敗となります。

重要：トリガー後にターンを早期終了しないでください（完了契約）

gh workflow run publish が成功しても、公開は完了していません。以前のセッションではこれを忘れ、ワークフローをトリガーしただけでターンを終了してしまいました。その結果、リリースの検証、拡張サマリーの作成、Discord への告知が未完了のまま残りました。この失敗を繰り返さないために、このセクションがあります。

ステップ 3（トリガー）の後は、実行が最終結果に達するまで進め、ターンを終了する前にトリガー後のすべてのステップを完了する必要があります。次のいずれかが未解決の間は、ターンを終了したり、引き継いだり、その日の作業を終えたりしてはいけません。

1. 実行結果 — gh run view <id> --json conclusion が success を返す必要があります（メモの作成中もポーリングしてください。何もせずに待機してはいけません）。
2. リリースの存在 — ステップ 5：gh release view v${NEW_VERSION} が成功します。
3. 拡張サマリーの適用 — ステップ 6 ＋ ステップ 7：作成（patch／minor／major では必須）し、gh release edit --notes-file で適用します。「Patch は任意」は誤りです。Patch のサマリーも必須です。
4. Discord への告知 — ステップ 7.5：agent-discordbot message send を試みます。メッセージ ID を記録するか、明確な失敗をユーザーに報告してください。Discord のステップを省略することは、ワークフローの失敗です。
5. npm の検証 — ステップ 8：npm view oh-my-opencode version（および oh-my-openagent、lazycodex-ai）が ${NEW_VERSION} を表示します。

5 項目すべてが完了してから、ターンを終了してください。実行に失敗した場合は、gh run view <id> --log-failed を実行して内容を報告し、そこで停止してください（公開の途中で作業ツリーを修復してはいけません）。トリガー後のステップが外部要因（npm の反映遅延、Discord の認証など）で失敗した場合は、明確に報告したうえで残りのステップを続行してください。1 つの失敗によって残りのステップを中断してはいけません。

この契約はスラッシュコマンドのコピー（.agents/command/publish.md、.opencode/command/publish.md）にも適用されます。.agents/AGENTS.md の差分ルールに従い、これらのファイルはこのスキルとバイト単位で同一に保たれています。

重要：引数の必須要件

ユーザーからリリース指定子を 1 つ受け取る必要があります。 有効な選択肢は次のとおりです。

• patch：バグ修正、後方互換性あり（1.1.7 → 1.1.8）
• minor：新機能、後方互換性あり（1.1.7 → 1.2.0）
• major：破壊的変更（1.1.7 → 2.0.0）
• プレリリース（5.0.0-beta.9 など）を含む、明示的な有効なセマンティックバージョン

ユーザーがリリース指定子を指定していない場合は、直ちに停止して次のように尋ねてください。

"デプロイを進めるには、patch、minor、major、または 5.0.0-beta.9 のような明示的なセマンティックバージョンを指定してください。"

それ以外の値は拒否してください。不正な形式のバージョンを推測したり、修正したりしてはいけません。

---

STEP 0：TODO リストの登録（最初に必ず実行）

何よりも先に、TodoWrite を使用して詳細な TODO リストを作成してください。

[
  { "id": "confirm-release-input", "content": "Confirm release selector with user (patch/minor/major or explicit semver)", "status": "in_progress", "priority": "high" },
  { "id": "check-uncommitted", "content": "Check for uncommitted changes and commit if needed", "status": "pending", "priority": "high" },
  { "id": "sync-remote", "content": "Sync with remote (pull --rebase && push if unpushed commits)", "status": "pending", "priority": "high" },
  { "id": "run-workflow", "content": "Trigger GitHub Actions publish workflow", "status": "pending", "priority": "high" },
  { "id": "wait-workflow", "content": "Wait for workflow completion (poll every 30s)", "status": "pending", "priority": "high" },
  { "id": "verify-and-preview", "content": "Verify release created + preview auto-generated changelog & contributor thanks", "status": "pending", "priority": "high" },
  { "id": "draft-summary", "content": "Draft enhanced release summary (mandatory for all release types)", "status": "pending", "priority": "high" },
  { "id": "apply-summary", "content": "Prepend enhanced summary to release", "status": "pending", "priority": "high" },
  { "id": "discord-announce", "content": "MANDATORY: post release announcement to Discord channel immediately after release notes are finalized", "status": "pending", "priority": "high" },
  { "id": "verify-npm", "content": "Verify npm package published successfully", "status": "pending", "priority": "high" },
  { "id": "verify-lazycodex", "content": "Verify lazycodex-ai publish, Codex plugin metadata version stamp, and code-yeongyu/lazycodex release/sync", "status": "pending", "priority": "high" },
  { "id": "verify-platform-binaries", "content": "Spot-check platform binary packages on npm", "status": "pending", "priority": "high" },
  { "id": "final-confirmation", "content": "Final confirmation to user with links", "status": "pending", "priority": "low" }
]

各 TODO は、着手時に in_progress、完了時に completed にしてください。一度に 1 つずつ進めてください。

---

STEP 1：リリース指定子の確認と分類

ユーザーがコマンド引数またはメッセージですでに指定子を提示している場合、それを確認として扱います。次のように一度だけ解析してください。

RELEASE_INPUT="${ARGUMENTS}"
if [[ "$RELEASE_INPUT" =~ ^(patch|minor|major)$ ]]; then
  RELEASE_KIND=bump
elif [[ "$RELEASE_INPUT" =~ ^([0-9]+\.){2}[0-9]+(-[0-9A-Za-z]+(\.[0-9A-Za-z]+)*)?$ ]]; then
  RELEASE_KIND=version
else
  echo "Invalid release selector: $RELEASE_INPUT" >&2
  exit 1
fi

指定子が提示されていない場合に限り、尋ねて返答を待ってください。

---

STEP 2：未コミットの変更を確認

実行：git status --porcelain

• 未コミットの変更がある場合は、ユーザーに警告し、先にコミットするか尋ねてください
• クリーンな場合は、続行してください

---

STEP 2.5：リモートと同期（必須）

プッシュされていないコミットがあるか確認します。

git log @{u}..HEAD --oneline

プッシュされていないコミットがある場合は、ワークフローをトリガーする前に必ず同期してください。

git pull --rebase && git push

これにより、GitHub Actions のワークフローが、すべてのローカルコミットを含む最新のコードで実行されます。

---

STEP 3：GitHub Actions ワークフローをトリガー

dev からディスパッチし、バージョン更新の指定子は bump を通じて、正確なバージョンは version を通じて渡します。明示的なバージョンでディスパッチする場合も、必須の bump 入力は patch のままですが、version が優先されるため、ワークフローでは無視されます。

if [ "$RELEASE_KIND" = bump ]; then
  RUN_URL="$(gh workflow run publish.yml --ref dev -f "bump=${RELEASE_INPUT}")"
else
  RUN_URL="$(gh workflow run publish.yml --ref dev -f bump=patch -f "version=${RELEASE_INPUT}")"
fi

if ! [[ "$RUN_URL" =~ ^https://github.com/code-yeongyu/oh-my-openagent/actions/runs/[0-9]+$ ]]; then
  echo "Publish dispatch did not return an exact workflow run URL: $RUN_URL" >&2
  exit 1
fi
RUN_ID="${RUN_URL##*/}"
if ! [[ "$RUN_ID" =~ ^[0-9]+$ ]]; then
  echo "Publish dispatch returned an invalid run ID: $RUN_ID" >&2
  exit 1
fi
gh run view "${RUN_ID}" --json databaseId,status,url --jq '{databaseId,status,url}'

返された実行 ID が、このリリース試行を識別します。最新の実行を検索して置き換えてはいけません。

STEP 4: ワークフローの完了を待つ

公開の実行は、順次進行するステージで構成された単一のワークフローです。想定所要時間は、最近の実際の実行では合計約30分です。

ステージ（ジョブ）	処理内容	目安
test / typecheck / codex-compatibility（3 OS）	リリースソースに対して CI のゲートを再実行します	4～8 分（Windows が最も時間のかかる箇所です）
prepare-release-state	バージョンを設定し、release: vX.Y.Z PR を作成して自動マージし、その PR に必須の CI チェックが完了するまで待ちます	10～15 分（主要なステージです）
publish-platform（ビルド＋公開、12 ターゲット）	2 系統のプラットフォームパッケージをビルドして公開します	3～4 分
publish-main → release	oh-my-opencode / oh-my-openagent / lazycodex-ai を公開し、GitHub リリースを作成して、code-yeongyu/lazycodex を同期します	4～6 分

30 秒ごとにジョブレベルのステータスを確認し、ステージの切り替わりをユーザーに報告してください。

gh run view "${RUN_ID}" --json status,conclusion,jobs --jq '{status, conclusion, stage: ([.jobs[] | select(.status=="in_progress") | .name] | join(", "))}'

重要：ポーリングループを使用し、sleep コマンドは使用しないでください。 待ち時間は、強化版リリース概要（ステップ 6）の下書きに活用してください。何もせずに待ったり、レビュー作業を始めたりしないでください。

結論が failure の場合は、エラーを表示して終了してください。

gh run view "${RUN_ID}" --log-failed

---

STEP 5: リリースを確認し、自動生成されたコンテンツをプレビューする

目的は2つです。リリースが存在することを確認し、次にワークフローがすでに生成した内容をユーザーに表示します。

# 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}'

リリースノートはリリース後ではなく、リリース前に作成されます。

リリース本文は、このバージョンに対応する CHANGELOG.md のセクションから抽出されます。ユーザー向けのノートは changes/unreleased/<pr-number>.md フラグメント（PR ごとに1つ、PR 番号をファイル名に使用）として追加し、/publish を実行する前に取り込みます。リリース状態の準備時に、この見出しが ## [<version>] - <UTC date> に設定され、リリース状態とともにコミットされるため、公開されるコミットにはすでにリリースノートが含まれています。

リリース本文に含まれる内容を正確にプレビューしてください。

bun run script/generate-changelog.ts > /tmp/contributors.md
bun run script/print-release-notes.ts "${NEW_VERSION}" /tmp/contributors.md

プレビューを実行した後、その出力をユーザーに提示し、次のように伝えてください。

これはリリースで公開される正確な本文です： まとめられたフラグメント、 チーム外の貢献者への謝辞、インストール用フッターの順に含まれます。

どちらの手順もフェイルクローズ方式です。セクションが存在しない、空である、または重複している場合は、 空のノートを公開せずにリリースを中止します。また、すでにセクションがあるバージョンの再設定も拒否されます。

changes/unreleased/ にフラグメントがない場合は、停止して先に作成してください。フラグメントなしではリリースを進められません。

承認ゲート（単一の二者択一）： ユーザーが最初に指定したバンプタイプ付きの公開リクエストが、このワークフローで必要となる唯一の承認です。ここで別途確認を待たないでください。プレビューを提示したら、ただちにステップ 6 に進んでください。唯一の例外は、ユーザーが「続行する前に変更履歴を確認させてください」（または同等の内容）と明示した場合です。その場合は停止して待ちます。それ以外の場合は、応答を終了せずに続行してください。

---

STEP 6: 強化版リリース概要を作成する

リリースタイプ	対応
patch	必須です。バグ修正や変更点の簡潔な概要を作成してください。概要を作成せずに先へ進まないでください。
minor	必須です。機能の簡潔な概要を作成してください。概要を作成せずに先へ進まないでください。
major	必須です。必要に応じて移行に関する注意事項を含む、詳細なリリース説明を作成してください。作成せずに先へ進まないでください。

OMO NATIVE CLI の一般公開前、最後のリリース

ユーザーが、このリリースを OmO Native CLI の一般公開前の最後のリリースだと指定した場合、GitHub の概要は必ずこの専用見出しから始めてください。また、Discord の告知でも @here の直後に専用見出しとして同じ文言を繰り返してください。

## LAST RELEASE BEFORE THE OMO NATIVE CLI PUBLIC RELEASE

作成する内容（および作成しない内容）

作成するのは見出しレイヤーです。自動生成されるコミットログの上に表示される、製品発表文です。「リリースブログ記事」をイメージしてください。「git log」ではありません。

- コミットメッセージを重複して記載してはいけません。自動生成セクションにすべてのコミットがすでに列挙されています。 - 「さまざまなバグ修正と改善」や「いくつかの機能強化」のような、ありきたりな埋め草を絶対に書いてはいけません。 - 常にユーザーへの影響に焦点を当ててください。これまでできなかったことで、ユーザーが今できるようになったことは何ですか？ - 常にコミットの種類（feat/fix/refactor）ではなく、テーマや機能ごとにまとめてください。 - 常に具体的な表現を使ってください。「X 機能を追加しました」ではなく、「X ができるようになりました」と書いてください。 - どちらのリリースノートのバリエーションにも、`senpi`、`omo-senpi`、`senpi-task`、`pi-goal`、`pi-webfetch` に該当する内部アダプターの変更を含めてはいけません。 ## 新機能 - feat(auth): JWT リフレッシュトークンのローテーションを追加 - fix(auth): 期限切れトークンのエッジケースに対応 - refactor(auth): ミドルウェアを抽出 ## 🔐 よりスマートな認証

トークンの更新が自動かつシームレスになりました。セッションがタスクの途中で期限切れになることはなくなり、システムがバックグラウンドで認証情報を目立たないようにローテーションします。突然ログアウトされることに悩まされていた方は、このリリースで解消されます。

## 改善 - さまざまなパフォーマンス改善 - バグ修正と安定性の強化 ## ⚡ ルール解析が 3 倍高速に

ルールがファイルの更新日時ごとにキャッシュされるようになりました。ルールファイルが 50 個以上あるプロジェクトでは、起動が明らかに速くなったと感じられるでしょう。テストスイートでは 3 倍の改善を測定しました。

作成手順

1. 分析 — Step 5 のプレビューにあるコミット一覧を分析します。ユーザーにとって重要なテーマを 2～5 個特定します。
2. 作成 — 要約を /tmp/release-summary-v${NEW_VERSION}.md に書き込みます。
3. 提示 — 適用する前に、確認と承認のために下書きをユーザーに提示します。

# 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

下書きをユーザーに提示してください： > 「リリース概要の下書きを作成しました。これはリリースノートの先頭、自動生成されるコミット変更履歴と貢献者への謝辞の上に表示されます。」

承認ゲート（同じ単一のゲート）： 最初の公開確認で、この手順もカバーします。下書きを提示したら、直ちに Step 7（適用）と Step 7.5（Discord）に進んでください。ユーザーが公開開始前にリリースノートのレビュー待ちを明示的に依頼していない限り、承認を待つために止まってはいけません。Discord でのお知らせ（Step 7.5）は必須です。依頼されていないレビュー待ちによって、これを妨げてはいけません。

---

STEP 7：強化した概要をリリースに適用する

この手順は必須です。Step 6 で作成した強化版の概要は、必ず適用してください。

最終的なリリースノートの構成：

┌─────────────────────────────────────┐
│  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   │
└─────────────────────────────────────┘

- まず既存のリリース本文を取得します - その上に概要を追加します - 既存の自動生成コンテンツは 100% そのまま残してください - 既存のコンテンツは、1 文字たりとも削除または変更してはいけません

# 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'

---

STEP 7.5: リリースノートを DISCORD に投稿

リリースノートが確定したら、Discord チャンネルに投稿します。この手順は、すべての公開実行で必須です。

次のいずれかを完了するまで、ワークフローは完了していません。 1. Discord メッセージを正常に送信し、メッセージ ID を記録する 2. `agent-discordbot auth status` の実行後に送信を1回再試行しても失敗し、リリースボットのトークンエラーをユーザーに報告する

リリースサマリーの承認待ちを理由に、この手順を省略してはいけません。ユーザーがすでに公開を承認している場合は、停止する前に Discord への投稿まで完了してください。

1. リリース告知には、`agent-discordbot` を使用してリリースボットのトークンを使います。これは必須のリリース経路です。ボット経路が利用できず、ユーザーが代替手段を明示的に承認した場合を除き、個人用の `agent-discord` トークンは使用しないでください。ローカルの `agent-discordbot` の現在のボットが変更されても、リリースメッセージがリリースボットから送信されるよう、ボット ID を固定してください。 ```bash RELEASE_BOT_ID=1486173823354146917 agent-discordbot auth status --bot "$RELEASE_BOT_ID" ```

2. 既存の告知スタイルに合わせるため、チャンネル内の最近のメッセージを読む：

RELEASE_BOT_ID=1486173823354146917
agent-discordbot message list 1454708427392680067 --bot "$RELEASE_BOT_ID" --limit 5

3. agent-discordbot が利用できない、または認証されていない場合は、停止してリリースボットのトークン経路が失敗したことを報告してください。その後に限り、agent-discord を使用するかどうかを人間が判断できます。

4. チャンネル 1454708427392680067 に、過去の告知スタイルに合わせてリリース告知を投稿します。メッセージは次の構成にしてください。

@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}

RELEASE_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 "$RELEASE_BOT_ID"

メッセージの送信に失敗した場合はユーザーに警告し、続行してください。Discord のエラーによって公開ワークフローをブロックしてはいけません。

---

STEP 8: NPM 公開を確認

新しいバージョンが表示されるまで npm レジストリをポーリングします。

npm view oh-my-opencode version

想定されるバージョンと比較します。2分後も一致しない場合は、npm の反映遅延についてユーザーに警告してください。

---

STEP 8.5: プラットフォームバイナリパッケージを抜き取り確認

プラットフォームパッケージは、同じ公開実行内の publish-platform ジョブによってビルドおよび公開されます。待機すべき別個のワークフローはなく、publish-main は一致するプラットフォームバイナリが存在しない限り公開しません。代表的なサンプルを抜き取り確認してください。

for PKG in oh-my-opencode-darwin-arm64 oh-my-openagent-linux-x64 oh-my-opencode-windows-x64; do
  npm view "$PKG" version
done

各パッケージで ${NEW_VERSION} が表示されるはずです。一致しない場合は、ユーザーに警告し、実行内の publish-platform ジョブを確認するよう案内してください。自分で再実行してはいけません。

---

STEP 9: 最終確認

次の情報を添えて、成功したことをユーザーに報告します。

• 新しいバージョン番号
• GitHub リリース URL：https://github.com/code-yeongyu/oh-my-opencode/releases/tag/v{version}
• npm パッケージ URL：https://www.npmjs.com/package/oh-my-opencode
• プラットフォームパッケージの状況：抜き取り確認したプラットフォームパッケージのバージョン

---

エラー処理

• ワークフローが失敗した場合：失敗したログを表示し、Actions タブを確認するよう提案します
• リリースが見つからない場合：反映遅延の可能性があるため、待機して再試行します
• npm が更新されていない場合：npm の反映には1～5分かかることがあるため、ユーザーに伝えます
• 権限が拒否された場合：ユーザーに gh auth login で再認証してもらう必要がある場合があります
• プラットフォームジョブが失敗した場合：同じ実行内の publish-platform ジョブのログを表示し、失敗したターゲットを明示して停止します。publish-main は、これらのジョブが成功するまで公開がブロックされる設計です

言語

ユーザーには英語で応答してください。