Extending and Contributing to OpenWork
1. Start with one runtime layer​
OpenWork has several clean extension surfaces:
| Goal | First place to look |
|---|---|
| Desktop UX | apps/app and apps/desktop |
| Host and orchestration behavior | orchestrator and host-mode surfaces |
| Plugin management | OpenCode plugin integration |
| Skills and templates | local workflow packaging surfaces |
| Debug and permission UX | session and control layers |
2. Why narrow changes matter​
Because OpenWork sits between a UI product and a runtime orchestrator, broad patches can get complicated quickly. Smaller surface-specific changes are easier to reason about and test.
3. Best first contributions​
- docs and onboarding fixes,
- permission UX improvements,
- host/client clarity,
- plugin or skills management polish,
- better debug exports or diagnostics.
4. Think in repeatable team workflows​
A good OpenWork contribution should improve:
- shareability,
- auditability,
- safety,
- or operator clarity.
5. Before opening a PR​
Validate the exact host, client, or plugin flow your patch affects and make sure the permission story remains clear from the user's point of view.