WorkBuddy skill lists: engineers and financial analysts are not the same thing
Community Discussion · General

WorkBuddy skill lists: engineers and financial analysts are not the same thing

KevinZhao_FinKevinZhao_FinOct 202026/10/20 193 views

This morning while scrolling CSDN I saw that article "WorkBuddy 10 High-Efficiency Skills," running from the springboot-scaffold project scaffold all the way to mcp-builder service construction. I did a quick check, and the list itself is fine, solidly written. But my first reaction after reading was, I probably won't use a single one of these ten skills.

I've used WorkBuddy for two months, and my scenarios are just two: post-market daily reports and research report breakdowns. So what I want to talk about is, with the same skill system, how should it be configured differently for a different role.

First let me explain two terms, so newbies don't get dizzy. Skill is just skill, and there's a line in the material I quite agree with:

A skill is essentially a solidified work protocol: what scenario triggers it, what goes in, what rules it processes by, what format it outputs.

MCP you can understand as an external data port plugged into WorkBuddy; once connected it can directly read data from some system, no need for you to manually import. The mcp-builder in that article is teaching you to build such a port yourself.

An engineer's skill is building things, my skill is verifying things. This difference determines that the configuration logic is completely different.

For example, their code-review is having AI review code logic. My corresponding skill is called caliber verification, and what it reviews is numbers. Open the WorkBuddy desktop version, click Skills in the left sidebar, then New Skill in the top right. The interface has just four input boxes: skill name, trigger words, processing rules, output format. Trigger words are what you say in the dialog box to automatically attach this skill; mine is set to the four characters "post-market daily report," type it and it calls itself.

The processing rules field is the whole focus, and also where newbies most easily gloss over things. What I wrote is these few items: first categorize by sector; under each sector every item must have a source and fetch time; items with no source found go separately into a "pending verification zone," not allowed into the main text; dates always take the system date of the task execution day, format YYYY-MM-DD.

That last sentence is something I dug out of a pit. Yesterday I even wrote a post saying WorkBuddy's daily briefing dates always get scrambled. At the time I thought it was a bug, but later when I dug into the skill config I found, if the rules don't hard-code the time anchor, it will sometimes take the system time, sometimes take the time mentioned in the material text, and once the two mix, the date drifts. After adding that sentence, my testing showed the hit rate went from seventy-something percent to over ninety percent. Not sure if all versions are like this, my environment is the desktop version, haven't tried the web version.

For output format I locked it to a Markdown table plus a pending verification list, so the daily output has a fixed structure, no need to readjust every day.

After configuring, hook up automation. Left sidebar Automation → New Task → execution time filled as 17:35, five minutes after close. File output path points to a fixed folder on the shared drive. Once this step is done, it means it runs itself before you get off work.

Now permissions. On my side three to four people view it, output directory on the shared drive, anyone can read; but the skill itself only I can modify. This must be locked down in advance, otherwise someone casually changes the rules, next day the output caliber all changes, and you can't even find who did it. I opened skill edit permission separately. Supposedly Skills installation and MCP configuration require the enterprise version, the personal version has some restrictions, I didn't dig deep into this, we use the enterprise version.

Maintenance is just two things, neither time-consuming. Every Friday I take last week's three daily reports and do a regression, mainly to see if the source links still open, some news sites retract articles. Once a month I clear the output folder, otherwise over a year there are thousands of files, finding things is slower than not looking.

For the MCP part I only connected one data port, to pull market quotes, that's enough. That article said some people connect a dozen, I think for analysts it's not very necessary, the more you connect, the harder it is to locate which link is the problem when something goes wrong.

Looking ahead, I judge that by this time next year, the batch running best in the skill market will be those that can write data sources directly into the output format. Finance, legal, and audit roles will run out first, because these roles have hard requirements for traceability, it's not a bonus point.

2 replies

?
Ctrl + Enter to reply
Ming
MingOct 20

I've stepped in this date-anchor pit too. If the rules aren't hardcoded it just drifts all over the place, and hit rate drops a solid thirty percent.

Sister Liang on Valuation
Reply to Ming

Hardcoding the anchor to the execution date is something I only added after getting burned too, but saying it drops thirty percent is a bit harsh. On my end it went from seventy-something to just over ninety, so the gap is probably whether the source material has timestamps or not.