菜单
Use when developing or refactoring OpenCode plugin handlers, tests, and daemon integration payloads
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when deploying pigeon code changes across all machines after merging to main
Use when you need to understand worker architecture, endpoint flow, and command routing behavior before making changes
Use when you need to understand daemon route flow, storage model, worker connectivity, and command injection architecture before making changes
Use when you need to understand the OpenCode plugin event lifecycle, session state transitions, and daemon API contracts
Use when you need to understand the swarm IPC subsystem — tables, routes, the per-target arbiter, the session→directory registry, and the wire envelope — before changing it
Use when implementing or testing swarm IPC features (new kinds, channels, plugin tools, or schema changes) with a TDD-first workflow
| name | opencode-plugin-development |
| description | Use when developing or refactoring OpenCode plugin handlers, tests, and daemon integration payloads |
Use this while implementing plugin behavior changes.
since cursor passthrough, HTTP error surfacing, formatter output, factory wiring through ToolContext.sessionID. Pattern: see test/swarm-tool.test.ts. Use tool({...}) from @opencode-ai/plugin/tool and patch globalThis.fetch only when exercising the factory's execute callback (the pure helper takes an injectable fetchFn).npm run --workspace @pigeon/opencode-plugin test
npm run --workspace @pigeon/opencode-plugin typecheck
globalThis.fetch to call OpenCode APIs -- in TUI mode no HTTP server is running on ctx.serverUrl. Use the SDK client's in-process fetch extracted at init time (see opencode-plugin-architecture skill)internalFetch, pass a new Request(url.toString(), init) object, not a bare URL -- the in-process Hono .fetch() requires a Requesttool and ToolDefinition from @opencode-ai/plugin/tool (subpath), NOT @opencode-ai/plugin. The upstream package's compiled JS uses extensionless ESM imports (import "./tool") which Node ESM rejects but the explicit ./tool subpath export resolves correctly. Bun handles the extensionless form fine; vitest under Node does not. If you ever see Cannot find module '/.../@opencode-ai/plugin/dist/tool' from a test or runtime, you imported from the bare package name — switch to the subpath.globalThis.fetch (the daemon listens on real TCP at 127.0.0.1:4731, unlike opencode serve in TUI mode). The pure helper should still accept an injectable fetchFn for tests.Expected: