What task are you trying to do?
We want PawWork's base harness to stay small and reliable while still supporting advanced capabilities through plugins when they are actually needed.
What do you do today?
The base tool registry exposes advanced or low-frequency tools alongside everyday tools. This increases prompt surface and can distract models, especially when some tools are not part of the common user path.
What would a good result look like?
The default base tools are few, stable, and broadly useful. Advanced tools such as codesearch, LSP, and GitHub or PR workflow helpers move behind plugins or another deferred surface. Skill remains on-demand, with only name and description exposed by default and full content loaded only when needed.
Which audience does this matter to most?
Both
Extra context
This issue is about default exposure and plugin boundaries only. It should not redefine subagent semantics, plan behavior, or the contents of individual tool prompts.
Technical prerequisite: Hooks.tool.register. The current PawWork / opencode plugin SDK (packages/plugin/src/index.ts) does not expose a way for a plugin to register a new AI tool. The Hooks interface only supports intercepting existing flows (auth, chat.headers, chat.params, config, event, and similar). Moving codesearch / LSP / GitHub tooling "behind plugins" therefore requires extending the SDK first with a tool.register hook (or equivalent) before any of the move work is possible.
Discussion from 2026-04-24 (see #30 body) concluded that extending the SDK is part of this issue's scope rather than a separate prerequisite issue. Whichever of #30 or #131 lands first owns the SDK extension; in practice this issue is the more likely owner because it is the one that actually needs the hook. Implementation: add tool.register to Hooks in packages/plugin/src/index.ts, wire it into Plugin.trigger in packages/opencode/src/plugin/index.ts so registered tools flow into the core tool registry, and gate exposure so only first-party plugins can register (matches the trust model decision in #30).
Acceptance criteria
- The base tool set is explicitly documented in code or config.
codesearch and lsp are removed from the default base prompt surface and moved to plugin-style exposure.
- GitHub, PR, and commit workflow helpers are not part of base Bash guidance.
- Skill remains available but only exposes lightweight metadata by default.
- The issue does not change the semantics of
subagent, plan, or todowrite.
Hooks.tool.register (or equivalent) is added to the plugin SDK and tool registration flows through it; the moved codesearch / LSP / GitHub tools are the first consumers.
What task are you trying to do?
We want PawWork's base harness to stay small and reliable while still supporting advanced capabilities through plugins when they are actually needed.
What do you do today?
The base tool registry exposes advanced or low-frequency tools alongside everyday tools. This increases prompt surface and can distract models, especially when some tools are not part of the common user path.
What would a good result look like?
The default base tools are few, stable, and broadly useful. Advanced tools such as codesearch, LSP, and GitHub or PR workflow helpers move behind plugins or another deferred surface. Skill remains on-demand, with only name and description exposed by default and full content loaded only when needed.
Which audience does this matter to most?
Both
Extra context
This issue is about default exposure and plugin boundaries only. It should not redefine subagent semantics, plan behavior, or the contents of individual tool prompts.
Technical prerequisite:
Hooks.tool.register. The current PawWork / opencode plugin SDK (packages/plugin/src/index.ts) does not expose a way for a plugin to register a new AI tool. TheHooksinterface only supports intercepting existing flows (auth,chat.headers,chat.params,config,event, and similar). Moving codesearch / LSP / GitHub tooling "behind plugins" therefore requires extending the SDK first with atool.registerhook (or equivalent) before any of the move work is possible.Discussion from 2026-04-24 (see #30 body) concluded that extending the SDK is part of this issue's scope rather than a separate prerequisite issue. Whichever of #30 or #131 lands first owns the SDK extension; in practice this issue is the more likely owner because it is the one that actually needs the hook. Implementation: add
tool.registertoHooksinpackages/plugin/src/index.ts, wire it intoPlugin.triggerinpackages/opencode/src/plugin/index.tsso registered tools flow into the core tool registry, and gate exposure so only first-party plugins can register (matches the trust model decision in #30).Acceptance criteria
codesearchandlspare removed from the default base prompt surface and moved to plugin-style exposure.subagent,plan, ortodowrite.Hooks.tool.register(or equivalent) is added to the plugin SDK and tool registration flows through it; the moved codesearch / LSP / GitHub tools are the first consumers.