WorkBuddy Skill Install: Pick the Path by How Much Code You Trust
A WorkBuddy skill install takes one of three routes, and the difference between them is not convenience. It is how much code you are accepting without reading it, and whether anyone other than you has looked at the package at all.
01 /Where does a WorkBuddy skill install begin?
Skills live in the left sidebar under Experts, Skills and Connectors. Adding one starts from the plus control on a skill card, and that single entry point fans out into four options: a built-in Skill, an uploaded local package, a search across available Skills, or a generated one built from your description. Three of those four are the paths below; the built-in option is a vendor package and sits outside the trust question this page is about. What a Skill is is worth reading first if the distinction between a Skill and a Connector is still unclear.
Knowing the entry point matters because people often assume there is a separate marketplace page with reviews. There is not, or at least not one that will tell you whether a package is safe. A WorkBuddy skill install has no review layer behind it, only a list and a search box, so the judgement stays with you at every step.
02 /Which of the three paths should you use?
Use the path whose trust requirement you can actually meet. That is the whole decision, and everything else on this page is detail hanging off it.
| Path | What you supply | Who vetted the code | Risk shape |
|---|---|---|---|
| Upload a local package | A package file you already have | You, and only you | Highest, because nothing was reviewed |
| Search for an existing Skill | A description of the task | Depends entirely on the source | Variable, often unknown |
| Create a custom Skill | A description of the task | The generator, not a reviewer | Low visibility, high surprise |
The table is not a ranking. A local package you wrote yourself is safer than a community package you found by searching, even though the first row is marked highest risk. Risk here is not a property of the route; it is a property of the route combined with where the code came from.
Path 1: upload a local package
You already have a Skill as a file. Drop it on the control or select it, and the client imports and configures it. This is the fastest path and the one with no intermediary: the package is code that will run with your permissions, and nobody reviewed it but you.
Use it when you built the package yourself, or when it came from a source you would trust with file access. If neither is true, this is the path where reading happens after the fact, which is the wrong order. A package is a folder of instructions plus scripts; opening it in a text editor takes two minutes and is the cheapest insurance available.
Path 2: search for an existing Skill
Describe the task, and the client searches for matching Skills and offers them for installation. The mechanics are the same as any app store search, and so is the failure mode: a match is not a review.
The risk depends entirely on where the matched package came from. A built-in or officially recommended Skill has passed vendor review. A community package has not, and the official security notice is explicit that non-official Skills may carry malicious prompt injection, privilege escalation or backdoors. This is the WorkBuddy skill install route most people take, which is precisely why the review question matters more here than anywhere else on the page. Use it when the task is common enough that someone has already built for it, and read the package before you enable it.
Path 3: create a custom Skill
Describe the task and the client generates the Skill. This is the path with the least obvious risk and the most hidden one: you know what you asked for, and you do not necessarily know what was produced. A generated package can include a dependency you did not name, a write path you did not expect, or a retry loop that will run far longer than you intended.
Read the output before relying on it, especially if it writes files or calls an external service. This is the path where the gap between the request and the artefact is widest, and the gap is invisible unless someone opens the result.
03 /What changes on the machine after the install?
A handful of behaviours are worth knowing before the list grows to twenty packages, because they determine how much of the risk you can undo later.
| Behaviour | What it means in practice |
|---|---|
| Disable without uninstalling | A disabled Skill is not called in conversation, and nothing has to be removed to stop it running |
| Enable only what the task needs | Tencent's own recommendation, aimed at noise, wrong invocations and credit spend |
| Keyword filter over installed Skills | The list becomes unreadable before it becomes unmanageable, so the filter is the practical tool |
| Removal is a separate action | Uninstalling from the machine is distinct from disabling, and supports batch removal |
Two of those rows are more useful than they look. Disabling being cheap means the safe default is to leave a package disabled until the task that needs it arrives, rather than enabling everything once and hoping. And batch removal existing at all is a hint about how the list usually ends up.
04 /What should you check right after a WorkBuddy skill install?
Three checks, each under a minute, that prevent most of the outcomes people actually complain about. Run them in this order, because the first one can stop a WorkBuddy skill install from being used at all.
- Which permissions did it request? File read and write, screen and input control, and third-party credentials are the three that matter. A Skill that formats text has no reason to ask for screen control, and a mismatch between stated purpose and requested permission is the single strongest signal available before you run anything.
- Does it send data out? Some Skills forward your input to an external service by design. Confirm the destination before feeding it anything sensitive, and note that "by design" and "disclosed" are different things.
- Run it on the smallest real sample you have. Five files instead of five hundred. A package that handles five correctly has not proven it handles five hundred, but one that fails on five has told you something cheap and early.
If a package fails the first check, stop there. The other two only matter for packages you have decided to trust enough to run.
05 /Does the scripts folder run on your machine?
Yes, and the vendor's position on it is worth stating plainly rather than paraphrasing into something softer. Tencent's security notice says that the scripts/ inside a Skill package execute in the client sandbox, and that the vendor does not take responsibility for the result of running those scripts. Checked on 2026-11-10.
That is not a scandal and it is not unusual for an extensibility layer, but it changes what an install means. You are not installing a configuration file; you are installing code whose behaviour the platform owner has declined to guarantee. Two things follow. Keep a backup of anything a Skill will write near, and prefer packages that write into a new path rather than overwriting in place, because a rollback is only cheap when the original still exists.
The sandbox matters here too, but it is a smaller comfort than it sounds. Per Tencent's cloud documentation, cloud tasks run in an isolated environment that does not support the local workspace or full access, while local task scripts execute on your own machine. A Skill that needs your files therefore runs on the less isolated of the two paths. Confusing the two is the most common category error in conversations about Skill safety, and it is the same confusion that makes the platform differences matter more than the download link itself.
06 /When there is no Skill for your case
The honest answer is to build one, or have one built, and then the question becomes whether the workflow is worth encoding at all.
A Skill is a package of scripts, so the test is whether your workflow has a fixed input, a fixed output and deterministic steps between them. If a person has to look at each item and decide, the Skill is not saving the judgement; it is pretending to. Those cases are cheaper to leave manual than to automate badly, and the custom page goes through where that boundary sits, including the four things worth sending before asking for anything.
One more consideration belongs here rather than there. Every package you install is a permanent small liability: it will keep being enabled, keep being a candidate for invocation, and keep needing to be checked when the client updates. Three packages you understand beat twelve you do not, and the difference is not discipline, it is knowing which three you actually use.
07 /Frequently asked questions
Do I need to uninstall a Skill to stop it running?
No. Disabling is enough, and it is reversible. A disabled Skill is not called in conversation, so the practical advice is to keep rarely used packages disabled and enable them for the task that needs them. Removal from the machine is a separate action and supports batch removal when the list has grown past the point of usefulness.
Is uploading a local package riskier than searching?
Usually, but not because of the upload itself. A searched package at least passed through a distribution channel that could have reviewed it, while an uploaded file arrived from wherever you got it. The rule that holds either way: the risk follows the source, not the route. A local package you wrote is safer than a community package you searched for.
What does a WorkBuddy skill install cost?
Browsing, uploading and managing Skills does not consume credits, according to Tencent's documentation. Consumption happens when the client executes a task, and tasks that are complex, or that use complex Skills, usually consume more. The official pages do not publish a per-call figure, and this site does not guess at one. The practical implication is to test a new package on a small batch before pointing it at a large folder.
Why does the vendor disclaim responsibility for Skill scripts?
Because the package is third-party code running under your identity, and the platform owner cannot audit every package. The official notice states that scripts in a package execute in the client sandbox and that the vendor does not take responsibility for the execution result, while also warning that a non-official Skill may carry prompt injection, privilege escalation or backdoors. Taken together, the position is consistent: the platform provides the mechanism, the user provides the judgement.
08 /Where should you go next?
- What a Skill actually is, and which permissions it can request: WorkBuddy Skills
- When nothing existing fits: custom Skill work
- Before any of this, the client has to be installed: WorkBuddy download
- The dated record of what broke, and when it was corrected: notes