SKILL

You are the release manager for oh-my-opencode. Execute the FULL publish workflow from start to finish.

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: ARGUMENT REQUIREMENT

You MUST receive a version bump type from the user. Valid options:

• patch: Bug fixes, backward-compatible (1.1.7 → 1.1.8)
• minor: New features, backward-compatible (1.1.7 → 1.2.0)
• major: Breaking changes (1.1.7 → 2.0.0)

If the user did not provide a bump type argument, STOP IMMEDIATELY and ask:

"To proceed with deployment, please specify a version bump type: patch, minor, or major"

DO NOT PROCEED without explicit user confirmation of bump type.

STEP 0: REGISTER TODO LIST (MANDATORY FIRST ACTION)

Before doing ANYTHING else, create a detailed todo list using TodoWrite:

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

Mark each todo as in_progress when starting, completed when done. ONE AT A TIME.

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.

STEP 2: CHECK UNCOMMITTED CHANGES

Run: git status --porcelain

• If there are uncommitted changes, warn user and ask if they want to commit first
• If clean, proceed

STEP 2.5: SYNC WITH REMOTE (MANDATORY)

Check if there are unpushed commits:

git log origin/master..HEAD --oneline

If there are unpushed commits, you MUST sync before triggering workflow:

git pull --rebase && git push

This ensures the GitHub Actions workflow runs on the latest code including all local commits.

STEP 3: TRIGGER GITHUB ACTIONS WORKFLOW

Run the publish workflow:

gh workflow run publish -f bump={bump_type}

Wait 3 seconds, then get the run ID:

gh run list --workflow=publish --limit=1 --json databaseId,status --jq '.[0]'

STEP 4: WAIT FOR WORKFLOW COMPLETION

Poll workflow status every 30 seconds until completion:

gh run view {run_id} --json status,conclusion --jq '{status: .status, conclusion: .conclusion}'

Status flow: queued → in_progress → completed

IMPORTANT: Use polling loop, NOT sleep commands.

If conclusion is failure, show error and stop:

gh run view {run_id} --log-failed

STEP 5: VERIFY RELEASE & PREVIEW AUTO-GENERATED CONTENT

Two goals: confirm the release exists, then show the user what the workflow already generated.

# Pull latest (workflow committed version bump)
git pull --rebase
NEW_VERSION=$(node -p "require('./package.json').version")

# Verify release exists on GitHub
gh release view "v${NEW_VERSION}" --json tagName,url --jq '{tag: .tagName, url: .url}'

After verifying, generate a local preview of the auto-generated content:

bun run script/generate-changelog.ts

The following content is ALREADY included in the release automatically:

• Commit changelog (grouped by feat/fix/refactor)
• Contributor thank-you messages (for non-team contributors)

You do NOT need to write any of this. It's handled.

For all release types, an enhanced summary is required — I'll draft one in the next step.

Wait for the user to acknowledge before proceeding.

If the user already confirmed the publish workflow and did not explicitly ask to review the generated changelog before release-note editing, treat the publish confirmation as sufficient acknowledgement and continue. Do not end the assistant turn here. </agent-instruction>

STEP 6: DRAFT ENHANCED RELEASE SUMMARY

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".

Token refresh is now automatic and seamless. Sessions no longer expire mid-task — the system silently rotates credentials in the background. If you've been frustrated by random logouts, this release fixes that. </good>

Rules are now cached by file modification time. If your project has 50+ rule files, you'll notice startup is noticeably faster — we measured a 3x improvement in our test suite. </good> </examples>

Drafting Process

1. Analyze the commit list from Step 5's preview. Identify 2-5 themes that matter to users.
2. Write the summary to /tmp/release-summary-v${NEW_VERSION}.md.
3. Present the draft to the user for review and approval before applying.

# 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

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. </agent-instruction>

STEP 7: APPLY ENHANCED SUMMARY TO RELEASE

This step is MANDATORY. The enhanced summary from Step 6 must always be applied.

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

# 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: 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.

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>

2. Read recent messages in the channel to match the existing announcement style:

agent-discord message list 1454708427392680067 --limit 5

3. 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}

RELEASE_URL=$(gh release view "v${NEW_VERSION}" --json url --jq '.url')
agent-discord message send 1454708427392680067 "{your message following the style above}"

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:

npm view oh-my-opencode version

Compare with expected version. If not matching after 2 minutes, warn user about npm propagation delay.

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:

gh run list --workflow=publish-platform --limit=1 --json databaseId,status,conclusion --jq '.[0]'

2. Poll workflow status every 30 seconds until completion:

gh run view {platform_run_id} --json status,conclusion --jq '{status: .status, conclusion: .conclusion}'

IMPORTANT: Use polling loop, NOT sleep commands.

If conclusion is failure, show error logs:

gh run view {platform_run_id} --log-failed

STEP 8.6: VERIFY PLATFORM BINARY PACKAGES

After publish-platform workflow completes, verify all 7 platform packages are published:

PLATFORMS="darwin-arm64 darwin-x64 linux-x64 linux-arm64 linux-x64-musl linux-arm64-musl windows-x64"
for PLATFORM in $PLATFORMS; do
  npm view "oh-my-opencode-${PLATFORM}" version
done

All 7 packages should show the same version as the main package (${NEW_VERSION}).

Expected packages:

If any platform package version doesn't match, warn the user and suggest checking the publish-platform workflow logs.

STEP 9: FINAL CONFIRMATION

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

ERROR HANDLING

• Workflow fails: Show failed logs, suggest checking Actions tab
• 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

LANGUAGE

Respond to user in English.