That One-Week WorkBuddy Review Was Right, But My Setup Order Was Reversed
Community Discussion · Company Watch

That One-Week WorkBuddy Review Was Right, But My Setup Order Was Reversed

SleepySleepy5d ago2026/09/28 115 views

Last night I came across a one-week hands-on review of WorkBuddy. The author ran it for a week and summed it up in one line: scope the directory first, then talk about the task; write the no-go zones first, then hit run. I felt sleepy reading it, but I sat up a bit straighter. Because I've been using WorkBuddy for about a month — all the odds and ends in my counseling office, meeting transcriptions, session note organizing, expense forms, notification templates for parents — I've thrown them all in there, and the pitfalls I hit basically line up.

That said, my order is a bit different from his. I clean up the territory and permissions first before I dare let it touch files.

First, the environment. I'm on the macOS desktop app, didn't look closely at the version, roughly 5.5-ish. The Windows UI should be similar, but I can't vouch for button positions — may not apply to everyone.

Step one is creating a workspace. Open WorkBuddy, there's a Workspace column on the left, click in, then New in the top right. It'll ask you to pick an existing folder or create a new one. I made one called "Counseling Office - Daily" and put only three kinds of things in it: meeting transcriptions, tables to be organized, and source material for drafts. This step looks redundant, but it's actually the most valuable step in the whole flow. The workspace is the territory you've carved out for it; outside that territory it can't see anything by default. The first time I used it, to save trouble, I just selected the entire "Documents" directory, and when I asked it to organize this week's to-dos, it scanned my personal memos too. That review also mentioned this same screw-up, so it seems I'm not the only one.

Step two is permissions. After the workspace is set up, click Settings in the top right, find the Permissions section. It gives three levels: allow means just do it, ask means ask every time, deny means refuse outright. My config: reading files inside the workspace is set to allow, writing and renaming files is set to ask, deletion is always deny, and a few paths are blacklisted outright, like the folder storing raw session records and the finance tables. After setting it up I tested once — asked it to break three transcripts into to-dos, and it dutifully produced a draft without touching the source files. That's the state I want. Last month I wrote a post about permissions; at the time I only covered those three levels. Now I'll add one thing: the workspace is the prerequisite, and permissions grow on top of the workspace.

Step three is skills. The word "Skill" is a bit confusing the first time you see it — you can think of it as a plugin or a small script. Once installed, it reads and writes files within your authorized scope, and some will send content to third-party services. At first I installed a bunch, capable of anything, and it looked great. Later I found that for a single task it would chain several skills together on its own, and by the time the job was done, my quota had dropped painfully. My habit now is to keep only what this task needs before starting, and turn them off when done. That review said don't treat having lots of skills installed as strong capability — I agree.

There's a line in the official skill docs I noted down: a Skill is essentially a script and workflow that reads and writes files and calls third-party services within the authorized scope.

Same goes for connectors. Email, Tencent Docs, Tencent Meeting — all can be connected, but what each can read and write depends on what you've actually authorized. I only connected Tencent Meeting and Tencent Docs, which is enough. Before connecting, I think clearly about what it's reading this for; if I can't answer that, I don't connect it.

Once it's running smoothly, I stick to one fixed chain: read-only first, let it produce a draft; I review it, mark sensitive fields and things to change; then authorize it to write to the target file; for anything sent externally, like notifications to parents, I click send myself. Two extra steps, but I sleep better than with one-line full automation.

There's also a small ops habit I do every Friday for ten minutes. Turn off temporary connectors that are done being used, clear out intermediate files generated in the workspace, and take another look at whether permissions were casually changed by some task. Sounds like OCD, but after getting burned once you stop thinking that. One time a task finished and wrote its output straight into the source directory — it didn't delete anything, but the filenames were a mess and I spent an afternoon hunting things down.

Workspace defines the boundary, permissions define the actions, skills control the cost — don't rush to let it work before these three things are settled.

My guess is that over the next half year, this kind of tool will compete on how to make people comfortable letting it work — permissions, collaboration, and cost all need to be worry-free. I'll run with this setup for now, and come back if I hit new pitfalls.

2 replies

?
Ctrl + Enter to reply
Gewu
Gewu4d ago

I agree that permissions live on the workspace, but isn't denying all deletes too rigid? Intermediate files need to be cleaned up too.

48hXiaotong

Last time I also just selected the entire document directory, and my private notes got scanned in. So embarrassing.