oh-my-opencode 4.3.1 → 4.5.0

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

@@ -0,0 +1,428 @@
+---
+name: publish
+description: "Publish oh-my-opencode to npm via GitHub Actions workflow. Argument: <patch|minor|major>. Triggers: publish, release, deploy, npm publish."
+---
+
+You are the release manager for oh-my-opencode. Execute the FULL publish workflow from start to finish.
+
+## 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:
+```bash
+git log origin/master..HEAD --oneline
+```
+
+**If there are unpushed commits, you MUST sync before triggering workflow:**
+```bash
+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:
+```bash
+gh workflow run publish -f bump={bump_type}
+```
+
+Wait 3 seconds, then get the run ID:
+```bash
+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:
+```bash
+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:
+```bash
+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.
+
+```bash
+# 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:**
+
+```bash
+bun run script/generate-changelog.ts
+```
+
+<agent-instruction>
+After running the preview, present the output to the user and say:
+
+> **The following content is ALREADY included in the release automatically:**
+> - Commit changelog (grouped by feat/fix/refactor)
+> - Contributor thank-you messages (for non-team contributors)
+>
+> You do NOT need to write any of this. It's handled.
+>
+> **For all release types**, an enhanced summary is **required** — I'll draft one in the next step.
+
+Wait for the user to acknowledge before proceeding.
+
+If the user already confirmed the publish workflow and did not explicitly ask to review the generated changelog before release-note editing, treat the publish confirmation as sufficient acknowledgement and continue. Do not end the assistant turn here.
+</agent-instruction>
+
+---
+
+## STEP 6: DRAFT ENHANCED RELEASE SUMMARY
+
+<decision-gate>
+
+| Release Type | Action |
+|-------------|--------|
+| **patch** | MANDATORY. Draft a concise bug-fix / change summary. Do NOT proceed without one. |
+| **minor** | MANDATORY. Draft a concise feature summary. Do NOT proceed without one. |
+| **major** | MANDATORY. Draft a full release narrative with migration notes if applicable. Do NOT proceed without one. |
+
+</decision-gate>
+
+### 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".
+
+<rules>
+- NEVER duplicate commit messages. The auto-generated section already lists every commit.
+- NEVER write generic filler like "Various bug fixes and improvements" or "Several enhancements".
+- ALWAYS focus on USER IMPACT: what can users DO now that they couldn't before?
+- ALWAYS group by THEME or CAPABILITY, not by commit type (feat/fix/refactor).
+- ALWAYS use concrete language: "You can now do X" not "Added X feature".
+</rules>
+
+<examples>
+<bad title="Commit regurgitation — DO NOT do this">
+## What's New
+- feat(auth): add JWT refresh token rotation
+- fix(auth): handle expired token edge case
+- refactor(auth): extract middleware
+</bad>
+
+<good title="User-impact narrative — DO this">
+## 🔐 Smarter Authentication
+
+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>
+
+<bad title="Vague filler — DO NOT do this">
+## Improvements
+- Various performance improvements
+- Bug fixes and stability enhancements
+</bad>
+
+<good title="Specific and measurable — DO this">
+## ⚡ 3x Faster Rule Parsing
+
+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.
+
+```bash
+# 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
+```
+
+<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?"
+
+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.
+
+<architecture>
+The final release note structure:
+
+```
+┌─────────────────────────────────────┐
+│  Enhanced Summary (from Step 6)     │  ← You wrote this
+│  - Theme-based, user-impact focused │
+├─────────────────────────────────────┤
+│  ---  (separator)                   │
+├─────────────────────────────────────┤
+│  Auto-generated Commit Changelog    │  ← Workflow wrote this
+│  - feat/fix/refactor grouped        │
+│  - Contributor thank-you messages   │
+└─────────────────────────────────────┘
+```
+</architecture>
+
+<zero-content-loss-policy>
+- Fetch the existing release body FIRST
+- PREPEND your summary above it
+- The existing auto-generated content must remain 100% INTACT
+- NOT A SINGLE CHARACTER of existing content may be removed or modified
+</zero-content-loss-policy>
+
+```bash
+# 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.
+
+<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:
+```bash
+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:
+```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
+
+After publish-platform workflow completes, verify all 7 platform packages are published:
+
+```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
+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.
+
+---
+
+## 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.

package/.agents/skills/remove-deadcode/SKILL.md

@@ -0,0 +1,216 @@
+---
+name: remove-deadcode
+description: "Remove unused code from this project with ultrawork mode, LSP-verified safety, atomic commits. Triggers: remove dead code, dead code, cleanup, remove unused."
+---
+
+
+Dead code removal via massively parallel deep agents. You are the ORCHESTRATOR — you scan, verify, batch, then delegate ALL removals to parallel agents.
+
+<rules>
+- **LSP is law.** Verify with `LspFindReferences(includeDeclaration=false)` before ANY removal decision.
+- **Never remove entry points.** `src/index.ts`, `src/cli/index.ts`, test files, config files, `packages/` — off-limits.
+- **You do NOT remove code yourself.** You scan, verify, batch, then fire deep agents. They do the work.
+</rules>
+
+<false-positive-guards>
+NEVER mark as dead:
+- Symbols in `src/index.ts` or barrel `index.ts` re-exports
+- Symbols referenced in test files (tests are valid consumers)
+- Symbols with `@public` / `@api` JSDoc tags
+- Hook factories (`createXXXHook`), tool factories (`createXXXTool`), agent definitions in `agentSources`
+- Command templates, skill definitions, MCP configs
+- Symbols in `package.json` exports
+</false-positive-guards>
+
+---
+
+## PHASE 1: SCAN — Find Dead Code Candidates
+
+Run ALL of these in parallel:
+
+<parallel-scan>
+
+**TypeScript strict mode (your primary scanner — run this FIRST):**
+```bash
+bunx tsc --noEmit --noUnusedLocals --noUnusedParameters 2>&1
+```
+This gives you the definitive list of unused locals, imports, parameters, and types with exact file:line locations.
+
+**Explore agents (fire ALL simultaneously as background):**
+
+```
+task(subagent_type="explore", run_in_background=true, load_skills=[],
+  description="Find orphaned files",
+  prompt="Find files in src/ NOT imported by any other file. Check all import statements. EXCLUDE: index.ts, *.test.ts, entry points, .md, packages/. Return: file paths.")
+
+task(subagent_type="explore", run_in_background=true, load_skills=[],
+  description="Find unused exported symbols",
+  prompt="Find exported functions/types/constants in src/ that are never imported by other files. Cross-reference: for each export, grep the symbol name across src/ — if it only appears in its own file, it's a candidate. EXCLUDE: src/index.ts exports, test files. Return: file path, line, symbol name, export type.")
+```
+
+</parallel-scan>
+
+Collect all results into a master candidate list.
+
+---
+
+## PHASE 2: VERIFY — LSP Confirmation (Zero False Positives)
+
+For EACH candidate from Phase 1:
+
+```typescript
+LspFindReferences(filePath, line, character, includeDeclaration=false)
+// 0 references → CONFIRMED dead
+// 1+ references → NOT dead, drop from list
+```
+
+Also apply the false-positive-guards above. Produce a confirmed list:
+
+```
+| # | File | Symbol | Type | Action |
+|---|------|--------|------|--------|
+| 1 | src/foo.ts:42 | unusedFunc | function | REMOVE |
+| 2 | src/bar.ts:10 | OldType | type | REMOVE |
+| 3 | src/baz.ts:7 | ctx | parameter | PREFIX _ |
+```
+
+**Action types:**
+- `REMOVE` — delete the symbol/import/file entirely
+- `PREFIX _` — unused function parameter required by signature → rename to `_paramName`
+
+If ZERO confirmed: report "No dead code found" and STOP.
+
+---
+
+## PHASE 3: BATCH — Group by File for Conflict-Free Parallelism
+
+<batching-rules>
+
+**Goal: maximize parallel agents with ZERO git conflicts.**
+
+1. Group confirmed dead code items by FILE PATH
+2. All items in the SAME file go to the SAME batch (prevents two agents editing the same file)
+3. If a dead FILE (entire file deletion) exists, it's its own batch
+4. Target 5-15 batches. If fewer than 5 items total, use 1 batch per item.
+
+**Example batching:**
+```
+Batch A: [src/hooks/foo/hook.ts — 3 unused imports]
+Batch B: [src/features/bar/manager.ts — 2 unused constants, 1 dead function]
+Batch C: [src/tools/baz/tool.ts — 1 unused param, src/tools/baz/types.ts — 1 unused type]
+Batch D: [src/dead-file.ts — entire file deletion]
+```
+
+Files in the same directory CAN be batched together (they won't conflict as long as no two agents edit the same file). Maximize batch count for parallelism.
+
+</batching-rules>
+
+---
+
+## PHASE 4: EXECUTE — Fire Parallel Deep Agents
+
+For EACH batch, fire a deep agent:
+
+```
+task(
+  category="deep",
+  load_skills=["typescript-programmer", "git-master"],
+  run_in_background=true,
+  description="Remove dead code batch N: [brief description]",
+  prompt="[see template below]"
+)
+```
+
+<agent-prompt-template>
+
+Every deep agent gets this prompt structure (fill in the specifics per batch):
+
+```
+## TASK: Remove dead code from [file list]
+
+## DEAD CODE TO REMOVE
+
+### [file path] line [N]
+- Symbol: `[name]` — [type: unused import / unused constant / unused function / unused parameter / dead file]
+- Action: [REMOVE entirely / REMOVE from import list / PREFIX with _]
+
+### [file path] line [N]
+- ...
+
+## PROTOCOL
+
+1. Read each file to understand exact syntax at the target lines
+2. For each symbol, run LspFindReferences to RE-VERIFY it's still dead (another agent may have changed things)
+3. Apply the change:
+   - Unused import (only symbol in line): remove entire import line
+   - Unused import (one of many): remove only that symbol from the import list
+   - Unused constant/function/type: remove the declaration. Clean up trailing blank lines.
+   - Unused parameter: prefix with `_` (do NOT remove — required by signature)
+   - Dead file: delete with `rm`
+4. After ALL edits in this batch, run: `bun run typecheck`
+5. If typecheck fails: `git checkout -- [files]` and report failure
+6. If typecheck passes: stage ONLY your files and commit:
+   `git add [your-specific-files] && git commit -m "refactor: remove dead code from [brief file list]"`
+7. Report what you removed and the commit hash
+
+## CRITICAL
+- Stage ONLY your batch's files (`git add [specific files]`). NEVER `git add -A` — other agents are working in parallel.
+- If typecheck fails after your edits, REVERT all changes and report. Do not attempt to fix.
+- Pre-existing test failures in other files are expected. Only typecheck matters for your batch.
+```
+
+</agent-prompt-template>
+
+Fire ALL batches simultaneously. Wait for all to complete.
+
+---
+
+## PHASE 5: FINAL VERIFICATION
+
+After ALL agents complete:
+
+```bash
+bun run typecheck   # must pass
+bun test            # note any NEW failures vs pre-existing
+bun run build       # must pass
+```
+
+Produce summary:
+
+```markdown
+## Dead Code Removal Complete
+
+### Removed
+| # | Symbol | File | Type | Commit | Agent |
+|---|--------|------|------|--------|-------|
+| 1 | unusedFunc | src/foo.ts | function | abc1234 | Batch A |
+
+### Skipped (agent reported failure)
+| # | Symbol | File | Reason |
+|---|--------|------|--------|
+
+### Verification
+- Typecheck: PASS/FAIL
+- Tests: X passing, Y failing (Z pre-existing)
+- Build: PASS/FAIL
+- Total removed: N symbols across M files
+- Total commits: K atomic commits
+- Parallel agents used: P
+```
+
+---
+
+## SCOPE CONTROL
+
+If `$ARGUMENTS` is provided, narrow the scan:
+- File path → only that file
+- Directory → only that directory
+- Symbol name → only that symbol
+- `all` or empty → full project scan (default)
+
+## ABORT CONDITIONS
+
+STOP and report if:
+- More than 50 candidates found (ask user to narrow scope or confirm proceeding)
+- Build breaks and cannot be fixed by reverting
+