القائمة
Use when developing or refactoring OpenCode plugin handlers, tests, and daemon integration payloads
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
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
استنادا إلى تصنيف SOC المهني
| 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: