2026-09-02 01:05:41 +08:00
commit 04bac1f6e2
2200 changed files with 489415 additions and 0 deletions
@@ -0,0 +1,17 @@
---
title: "Control the browser"
description: "How to use OpenWork to automate the built-in browser"
---
Computer-use in OpenWork currently works through the built-in OpenWork Browser. It does not yet mean full desktop control of Ubuntu, macOS, or Windows apps.
OpenWork can open pages, click, fill forms, read page content, and take screenshots inside that browser. If you connect to a remote OpenWork server, the browser runs on that remote worker.
Today, the supported path is the first-party `OpenWork Browser` extension.
## Requirements
- Use the desktop app or a remote worker that exposes the OpenWork Browser.
- Keep `OpenWork Browser` enabled in `Settings > Library`.
Then go back to the session view and ask OpenWork to open a website.
@@ -0,0 +1,59 @@
---
title: "Create a skill from chat"
description: "Turn a useful OpenWork chat into a reusable skill"
---
<Note>
**Choose where the skill lives.** A local workspace skill is free and requires no OpenWork Cloud sign-in. When you are signed in and ask OpenWork to create a skill “for me,” it creates a private Cloud plugin that only you can access. Owners and admins can publish managed team skills through [Collections](/cloud/share-with-your-team/collections).
</Note>
Do the work once in chat before you turn it into instructions.
## Turn a useful chat into a personal Cloud skill
1. Finish the task in chat and keep the thread open.
2. Ask in plain English: `Turn what we just did into a reusable skill for me`.
3. OpenWork saves the skill in your OpenWork Cloud organization as a private plugin. You receive access automatically; it is not written into your workspace or shared with anyone else.
4. Give the skill a clear name if OpenWork asks, then let it confirm what it saved. In the desktop app you get a rich confirmation card with the skill name and a link to it in your Library.
5. Use it later by name in chat, or describe the same kind of task and let OpenWork trigger it when it matches.
<Frame>
  ![Chat with the skill-created confirmation card showing the new skill, its plugin, and an Open in Library link](/images/skill-created-mcp-app-card.png)
</Frame>
## Other ways to create a skill
Every path creates the same thing: a skill inside a plugin in your OpenWork Cloud organization.
- **Desktop, from the Library**: open `Settings` > `Library`, filter to `Skills`, and click `Add skill`. This requires being signed in to OpenWork Cloud; the skill is created as a private plugin in your organization.
<Frame>
  ![Library filtered to Skills with the Add skill button](/images/library-skills-add-skill.png)
</Frame>
<Frame>
  ![Create a skill modal with name, description, skill body, and who can use it](/images/library-create-skill-modal.png)
</Frame>
- **Cloud dashboard**: organization admins create and edit skills inside a plugin from `Plugin Directory` — open a plugin and add a skill to it.
<Frame>
  ![Cloud dashboard plugin page with its skills and the Add skill button](/images/cloud-plugin-add-skill.png)
</Frame>
<Frame>
  ![Cloud dashboard skill editor reached from a plugin's Add skill button](/images/cloud-skill-editor.png)
</Frame>
- **From chat**, as described above.
## Change or share it only when you choose
1. To refine it, ask for the change in chat, such as `Make the skill ask before sending email`.
2. To share it with teammates, add its plugin to a Collection and grant that Collection by following [Publish and copy a skill](/start-here/do-work-with-it/publish-and-copy-a-skill).
<Note>Creating the skill does not publish it. Sharing is a separate step you choose.</Note>
## Keep a skill local to one workspace
A local skill is a `SKILL.md` file inside your workspace (for example `.opencode/skills/<name>/SKILL.md`). If you explicitly ask for a local skill in chat, OpenWork creates only that file and does not make a Cloud copy. Local skills need no Cloud account and remain available in `Settings > Library`, but OpenWork Cloud cannot assign or update them for your team.
@@ -0,0 +1,40 @@
---
title: "Cross-chat memory"
description: "How OpenWork can answer questions about past sessions."
---
OpenWork's cross-chat memory currently comes from saved session history. It is not a separate long-term memory database, and it does not automatically inject every old chat into every new prompt.
When an agent is running inside the OpenWork app, it can use OpenWork's semantic UI actions to look up past chats:
- `session.list_sessions` lists recent sessions across the workspaces the app knows about.
- `session.open` opens a matching session by ID.
- `session.read_transcript` reads recent messages from the currently open session.
- `session.latest_message` reads the newest message in the currently open session.
That means you can ask things like:
- `What did I say in the customer migration session?`
- `Find the session about Ramki and remind me what we decided.`
- `Open the onboarding bug chat and summarize the next steps.`
- `What did I ask you to do in session ses_abc123?`
## What happens
1. The agent lists sessions and matches by session ID, title, workspace, or topic words you provided.
2. If there is one clear match, the agent opens that session.
3. The agent reads the transcript and answers from the returned messages.
4. If there are multiple likely matches, the agent asks which session you meant.
Because this uses the OpenWork UI, the agent may briefly navigate away from your current session to inspect another one. You can ask it to return to the current session afterward.
## Current limits
- Session lookup is based on the sessions OpenWork has loaded for the current app and workspace context.
- Transcript reads return a bounded set of recent messages from the opened session. If an older part of a long chat is not returned, the agent should say that instead of guessing.
- This is not semantic search over every message yet. Clear titles, session IDs, workspace names, or topic clues help the agent find the right chat.
- The agent can only read sessions available to the current OpenWork app and user.
## How to ask
Give the agent whatever clue you have: a session ID, title, person name, project name, workspace, or rough topic. For example: `Use the OpenWork app UI to find the customer migration chat and tell me what I said about customer references.`
@@ -0,0 +1,26 @@
---
title: "Publish and copy a skill"
description: "Publish a skill through a Cloud Collection or copy it without changing the shared original"
---
<Note>
**Personal or managed.** Local workspace skills remain free and need no OpenWork Cloud sign-in. Cloud members can also create personal skills for themselves today. Publishing a skill for other people is a managed Cloud flow for owners and admins by default.
</Note>
## Publish a skill for your team
1. In the Cloud dashboard, open `Plugin Directory` and create or open a plugin.
2. Add a skill inside the plugin. Give it a clear name, describe when the agent should use it, and write the instructions.
3. In the plugin's `Share` section, choose a `Collection`. If you need a new one, open `Collections`, click `New collection`, and then return to the plugin.
4. Open that Collection and use `Who can access this` to grant it to everyone in the organization, selected teams, or individual members.
5. Assigned members find the plugin and its skill in `Settings > Library` in the desktop app. The plugin creator keeps access automatically.
Only owners and admins can create and publish skills for other people by default. Members can currently create personal skills for themselves. An admin restriction that prevents members from creating their own skills is in development.
Follow [Team quickstart](/cloud/team-quickstart) for the complete first-time setup. Use [Collections](/cloud/share-with-your-team/collections) when you need to group several plugins, reuse the same audience, or manage more complex assignments.
## Copy without changing the shared skill
Create a new private plugin, copy the skill instructions into a new skill, and edit that copy. Do not edit the team plugin unless everyone assigned to its Collection should receive the change.
For a small personal adjustment, you can instead create a new skill that tells the agent to use the shared skill first and then apply your extra instructions.
@@ -0,0 +1,18 @@
---
title: "Share skills with your team"
description: "Find personal and team skills in the Library, then share managed skills through Cloud Collections"
---
<Note>
**Local or managed.** Local workspace skills remain free and require no OpenWork Cloud sign-in; copy their files yourself when you only need an unmanaged handoff. For centrally assigned team skills and updates, publish a plugin through an OpenWork Cloud [Collection](/cloud/share-with-your-team/collections).
</Note>
OpenWork no longer shares skills from a `Workspace > Skills` screen. The desktop app shows what is already available to your agent.
## Find shared skills
1. Open `Settings > Library` in the desktop app.
2. Use the `Skills` filter or search to find skills from your workspace and organization.
3. Click a skill and choose `View details` to read its description; local skills can be revealed or removed, while OpenWork Connect skills are read-only.
4. Click `Refresh` if an admin just updated a Collection or changed your access.
5. To publish or customize a skill for teammates, follow [Publish and copy a skill](/start-here/do-work-with-it/publish-and-copy-a-skill). For larger setups with several plugins or audiences, see [Collections](/cloud/share-with-your-team/collections).
@@ -0,0 +1,46 @@
---
title: "Connectors, skills, and plugins"
description: "Use connectors for systems and plugins for the skills that make a system usable"
---
OpenWork gives agents a small set of building blocks. The connector reaches the system; the skill is the playbook; the plugin is the bundle; the Library is where you see what you have.
## Choose the right unit
| Use | Means | Reach for it when |
| --- | --- | --- |
| Connector | An MCP service your organization adds standalone, without wrapping it in a plugin. | The agent needs to act in that system after you connect it once. |
| Connection | Your own signed-in instance of a connector, one per user. | You sign in so the agent acts as you in that system. |
| Skill | Written instructions the agent loads when a task matches. | One repeatable way of doing work needs a playbook. |
| Plugin | A bundle — skills, MCP servers, and other components packaged and distributed as one thing. | Several related pieces should travel together. |
| Library | The list of active elements you have access to, in the desktop app and the Cloud dashboard. | You want to see or manage what is already available to you. |
MCP is the open standard underneath many connectors, and the [OpenWork MCP Gateway](/cloud/run-in-the-cloud/cloud-mcp) is how all of it reaches your agent — but day to day you can think in terms of connectors, skills, plugins, and your Library.
## Connect the system first
Use connectors for the apps themselves. In the desktop app, start in `Settings` > `OpenWork Connect`; for the click-by-click flow, see [Connect your services](/start-here/connect-your-stack/connect-services).
Everything your agent can use is listed in `Settings` > `Library`, under `Available apps` and `Your apps`. Use `Add Custom App` to connect something we do not list yet.
## Add skills when the connector is thin
A connector may reach your ticketing system but still be awkward: an incident may need exact fields, a priority change may need a safe sequence, or one ticket action may behave badly.
Write skills for those system rules:
- how to file an incident with the right fields;
- how to update a customer note without losing context;
- how to work around an unreliable ticket action.
These skills describe the system, not one person's style, so everyone who uses that system needs them.
## Bundle system skills into a plugin
Everything is a plugin under the hood. When you ask OpenWork to create a skill, OpenWork creates a small plugin containing that one skill, so “skill or plugin?” is not a decision most people need to make.
The useful plugin case is a thin connector with several system skills. If half a dozen ticketing skills make one system usable, bundle them into one plugin — the ticketing unit — and share that single thing. For distribution options, see [Publish and copy a skill](/start-here/do-work-with-it/publish-and-copy-a-skill).
## Keep personal skills separate
Use connectors for systems. Use plugins to bundle the skills that make a system usable. Personal or workflow-specific skills can stay individual unless a team should receive them together.
@@ -0,0 +1,23 @@
---
title: "What uses tokens"
description: "Understand when OpenWork model usage starts and how to control it."
---
OpenWork uses model tokens when a member actually runs work. Setup actions do not consume tokens by themselves.
## Know when usage starts
1. Sending a prompt runs the selected model and consumes tokens. Running a skill does the same because the skill is loaded into the task and the model follows its instructions.
2. There is no result cache today: rerunning the same task sends a new model request.
3. Usage scales with the context the agent has to read, including long transcripts, pasted text, file attachments, and tool results.
4. Tasks that make more tool calls usually cost more because the agent reads results and decides the next step.
5. Prompt cards do not cost anything while they sit in a policy, no matter how many an admin configures. Installing skills or publishing plugins through Collections also costs nothing until a member runs a task that uses them.
6. A good skill can reduce cost by making repeat work shorter and more deterministic, with fewer exploratory tool calls.
## Control spend today
1. Keep prompt cards short and specific.
2. Prefer focused skills for repeat workflows.
3. Attach only the files and transcript context the task needs.
4. Ask for narrow outputs before broad analysis.
5. Watch for tasks that loop through many tools, then turn the successful path into a skill.
@@ -0,0 +1,10 @@
---
title: "Workflows"
description: "Use chat and session groups to keep OpenWork organized."
---
Workflows are how you turn normal OpenWork chats into organized, repeatable work. In the UI, every session can be renamed, pinned, archived, reordered, or moved into a custom group folder from the session menu. Group folders are workspace-specific: create a group like `Research`, `Ready for review`, `Shipped`, or `Bugs`, then move sessions into that group as the work changes.
You can also describe the workflow in the composer while you work. For example: `When this is done, rename the session to "Auth cleanup", move it to Ready for review, and pin it`, or `If this turns into a bug investigation, put it in Bugs; otherwise archive it when finished.` Those instructions map to OpenWork's session management primitives: `rename` changes the session title, `move to group` stores a session-to-group assignment, `pin` keeps important sessions at the top, `archive` hides finished sessions without deleting them, and manual ordering lets you arrange sessions and groups around your process.
This makes session organization dynamic instead of manual bookkeeping. A team can keep groups for `Triage`, `In progress`, `Needs human review`, and `Done`, then ask OpenWork in chat to classify future sessions into those buckets as work completes. The exact groups and actions are configurable from the UI, so the workflow can match how you already work instead of forcing a fixed project-management structure.